高併發系統保護 ing

由於公司業務發展，需要考慮一些高併發系統保護的問題，整理記錄一下。

當發現你的系統出現訪問卡頓，伺服器各種效能指標接近100%（如果乙個初創型企業系統正常運**況下出現這個問題，那麼應該恭喜你，你懂得），首先想到的是該加機器了，現在要說的並不是加機器的事，而是說在高併發的情況下，從**層面如何保護系統，記得某位大神的部落格裡講過「在開發高併發系統時，有三把利器用來保護系統：快取、降級和限流」。通過快取，降級，限流能夠很好地給你的系統加個保護罩。

快取是一種提高系統讀效能的常見技術，對於讀多寫少的應用場景，我們經常使用快取來進行優化。由於大部分的請求時查詢，通過快取能夠極大降低資料庫的壓力。快取的做法多種多樣，客戶端可以做快取，服務端可以做快取。

當前主要的快取方式有檔案快取，利用nosql快取，一大坨資料通過一定的演算法和配置分攤到集群中的若干臺機器上（系統足夠大的時候這麼幹比較好）。當前用的比較多的

（1）檔案快取

（2）redis ，memcache利用記憶體讀取速度，達到高速查詢的目的

當訪問量劇增、服務出現問題（如響應時間慢或不響應）或非核心服務影響到核心流程的效能時，仍然需要保證服務還是可用的，即使是有損服務。系統可以根據一些關鍵資料排查，進行系統降級。

那麼何為降級呢，降級其實總結起來就四個字「棄卒保帥」。舉個例子來講，拿電商**來說吧，降級要做到的，保證核心購物流程，將級其他非核心業務功能。

降級的功能點主要從服務端鏈路考慮，從使用者訪問的角度，來梳理那些服務或者功能需要降級。

頁面降級：在大促或者某些特殊情況下，某些頁面占用了一些稀缺服務資源，在緊急情況下可以對其整個降級，以達到丟卒保帥；

頁面片段降級：比如商品詳情頁中的商家部分因為資料錯誤了，此時需要對其進行降級；

讀服務降級：比如多級快取模式，如果後端服務有問題，可以降級為唯讀快取，這種方式適用於對讀一致性要求不高的場景；

寫服務降級：比如秒殺搶購，我們可以只進行cache的更新，然後非同步同步扣減庫存到db，保證最終一致性即可，此時可以將db降級為cache。(常用手段)

…降級手法比較多，在這裡就不一一說了。

所謂限流，顧名思義，就是限制流量，通過限流我們可以很好地控制系統的qps，從而達到保護系統的目的。

常用的演算法有，計數器法（有臨界值問題），漏桶演算法，令牌桶演算法。由於令牌桶演算法由於實現簡單，且允許某些流量的突發，對使用者友好，所以被業界採用地較多。現在就來搞一下令牌桶演算法。

為了更好的理解令牌桶演算法，先附個圖：

理解：有乙個固定容量的桶，桶裡存放著令牌（token）。桶一開始是空的，token以乙個固定的速率r往桶裡填充，直到達到桶的容量，多餘的令牌將會被丟棄。每當乙個請求過來時，就會嘗試從桶裡移除乙個令牌，如果沒有令牌的話，請求無法通過。直接上**

//令牌桶偽**走起
public
class
tokenbucket
else
}}

高併發系統保護 ing

高併發系統保護 ing

高併發系統保護 ing

高併發系統設計

相關推薦