聊聊高并發之隔離術
隔離是指將系統或資源分割開，系統隔離是為了在系統發生故障時能限定傳播范圍和影響范圍，即發生故障后不會出現滾雪球效應，從而保證只有出問題的服務不可用，其他服務還是可用的;而資源隔離有臟數據隔離、通過隔離后減少資源競爭提升性能等。我遇到的比較多的隔離手段有線程隔離、進程隔離、集群隔離、機房隔離、讀寫隔離、動靜隔離、爬蟲隔離等。而出現系統問題時可以考慮負載均衡路由、自動/手動切換分組或者降級等手段來提升可用性。
線程隔離
線程隔離主要有線程池隔離，在實際使用時我們會把請求分類，然后交給不同的線程池處理，當一種業務的請求處理發生問題時，不會將故障擴散到其他線程池，從而保證其他服務可用。
我們會根據服務等級劃分兩個線程池，以下是池的抽象：
- <bean id="zeroLevelAsyncContext" class="com.jd.noah.base.web.DynamicAsyncContext" destroy-method="stop">
- <property name="asyncTimeoutInSeconds" value="${zero.level.request.async.timeout.seconds}"/>
- <property name="poolSize" value="${zero.level.request.async.pool.size}"/>
- <property name="keepAliveTimeInSeconds" value="${zero.level.request.async.keepalive.seconds}"/>
- <property name="queueCapacity" value="${zero.level.request.async.queue.capacity}"/>
- </bean>
- <bean id="oneLevelAsyncContext" class="com.jd.noah.base.web.DynamicAsyncContext" destroy-method="stop">
- <property name="asyncTimeoutInSeconds" value="${one.level.request.async.timeout.seconds}"/>
- <property name="poolSize" value="${one.level.request.async.pool.size}"/>
- <property name="keepAliveTimeInSeconds" value="${one.level.request.async.keepalive.seconds}"/>
- <property name="queueCapacity" value="${one.level.request.async.queue.capacity}"/>
- </bean>
進程隔離
在公司發展初期，一般是先進行從0到1，不會一上來就進行系統的拆分，這樣就會開發出一些比較大而全的系統，系統中的一個模塊/功能出現問題，整個系統就不可用了。首先想到的解決方案是通過部署多個實例，然后通過負載均衡進行路由轉發，但是這種情況無法避免某個模塊因BUG而出現如OOM導致整個系統不可用的風險。因此此種方案只是一個過渡，較好的解決方案是通過將系統拆分為多個子系統來實現物理隔離。通過進程隔離使得某一個子系統出現問題不會影響到其他子系統。
集群隔離
隨著系統的發展，單實例服務無法滿足需求了，此時需要服務化技術，通過部署多個服務，形成服務集群來提升系統容量，如下圖所示
隨著調用方的增多，當秒殺服務被刷會影響到其他服務的穩定性，此時應該考慮為秒殺提供單獨的服務集群，即為服務分組，從而當某一個分組出現問題不會影響到其他分組，從而實現了故障隔離，如下圖所示
比如注冊生產者時提供分組名：
- <jsf:provider id="myService" interface="com.jd.MyService" alias="${分組名}" ref="myServiceImpl"/>
消費時使用相關的分組名即可：
- <jsf:consumer id="myService" interface="com.jd.MyService" alias="${分組名}"/>
機房隔離
隨著對系統可用性的要求，會進行多機房部署，每個機房的服務都有自己的服務分組，本機房的服務應該只調用本機房服務，不進行跨機房調用;其中一個機房服務發生問題時可以通過DNS/負載均衡將請求全部切到另一個機房;或者考慮服務能自動重試其他機房的服務從而提升系統可用性。
一種辦法是根據IP(不同機房IP段不一樣)自動分組，還一種較靈活的辦法是通過在分組名中加上機房名解決：
- <jsf:provider id="myService" interface="com.jd.MyService" alias="${分組名}-${機房}" ref="myServiceImpl"/>
- <jsf:consumer id="myService" interface="com.jd.MyService" alias="${分組名}-${機房}"/>
讀寫隔離
如下圖所示，通過主從模式將讀和寫集群分離，讀服務只從從Redis集群獲取數據，當主Redis集群出現問題時，從Redis集群還是可用的，從而不影響用戶訪問;而當從Redis集群出現問題時可以進行其他集群的重試。
--先讀取從
- status, resp = slave_get(key)
- if status == STATUS_OK then
- return status, value
- end
如果從獲取失敗了，從主獲取
- status, resp = master_get(key)
動靜隔離
當用戶訪問如結算頁時，如果JS/CSS等靜態資源也在結算頁系統中時，很可能因為訪問量太大導致帶寬被打滿導致出現不可用。
因此應該將動態內容和靜態資源分離，一般應該將靜態資源放在CDN上，如下圖所示
爬蟲隔離
在實際業務中我們曾經統計過一些頁面型應用的爬蟲比例，爬蟲和正常流量的比例能達到5:1，甚至更高。而一些系統是因為爬蟲訪問量太大而導致服務不可用;一種解決辦法是通過限流解決;還一種解決辦法是在負載均衡層面將爬蟲路由到單獨集群，從而保證正常流量可用，爬蟲流量盡量可用。
比如最簡單的使用Nginx可以這樣配置：
- set $flag 0;
- if ($http_user_agent ~* "spider") {
- set $flag "1";
- }
- if($flag = "0") {
- //代理到正常集群
- }
- if ($flag = "1") {
- //代理到爬蟲集群
- }
實際場景我們使用了Openresty，不僅僅對爬蟲user-agent過濾，還會過濾一些惡意IP(統計IP訪問量，配置閥值)，將他們分流到固定分組。還有一種辦法是種植Cookie，訪問特殊服務前先種植Cookie，訪問服務時驗證該Cookie，如果沒有或者不對可以考慮出驗證碼或者分流到固定分組。
熱點隔離
秒殺、搶購屬于非常合適的熱點例子;對于這種熱點是能提前知道的，所以可以將秒殺和搶購做成獨立系統或服務進行隔離，從而保證秒殺/搶購流程出現問題不影響主流程。
還存在一些熱點可能是因為價格或突發事件引起的;對于讀熱點我使用多級緩存搞定;而寫熱點我們一般通過緩存+隊列模式削峰，可以參考《前端交易型系統設計原則》。
資源隔離
最常見的資源如磁盤、CPU、網絡;對于寶貴的資源都會存在競爭問題。
在《構建需求響應式億級商品詳情頁》中我們使用JIMDB數據同步時要dump數據，SSD盤容量用了50%以上，dump到同一塊磁盤時遇到了容量不足的問題，我們通過單獨掛一塊SAS盤來專門同步數據。還有如使用Docker容器時，有的容器寫磁盤非常頻繁，因此要考慮為不同的容器掛載不同的磁盤。
默認CPU的調度策略在一些追求***性能的場景下可能并不太適合，我們希望通過綁定CPU到特定進程來提升性能。如我們一臺機器會啟動很多個Redis實例，通過將CPU通過taskset綁定到Redis實例上可以提升一些性能;還有Nginx提供了worker_processes和worker_cpu_affinity來綁定CPU。還有如系統網絡應用比較繁忙的話，可以考慮綁定網卡IRQ到指定的CPU來提升系統處理中斷的能力，從而提升性能。
還有如大數據計算集群、數據庫集群應該和應用集群隔離到不同的機架，并盡量隔離網絡;因為大數據計算或數據庫同步時時會有比較大的網絡帶寬，可能擁塞網絡導致應用響應慢。
還有一些其他類似的隔離術，如環境隔離(測試環境、預發布環境/灰度環境、正式環境)、壓測隔離(真實數據、壓測數據隔離)、ABTest(為不同的用戶提供不同版本的服務)、緩存隔離(有些系統混用緩存，而有些系統會扔大字節值到如Redis，造成Redis慢查詢)、查詢隔離(簡單、批量、復雜條件查詢分別路由到不同的集群)等。通過隔離后可以將風險降低到***、性能提升至***。
【本文是51CTO專欄作者張開濤的原創文章，作者微信公眾號：開濤的博客( kaitao-1234567)】
