1.背景
最近遇到了線上服務的雪崩，查查資料，整理整理。
離線架構更多的是考慮數據寫入時的，
- 成功率，建庫成功率有幾個9
- 吞吐量，上億數據多久可以完成建庫。
- 數據一致性，機房間、同機房副本間。
- 延時，單條數據的寫入時間分位值。離線對延時要求可能不嚴格。
在線架構更多的是考慮數據讀取時的，
- 成功率，後端存儲穩定性，是否有熱點數據。
- qps，系統能支持的併發請求量
- 一致性，排序、策略等是否一致。
- 對時間的延時要求很高。通常一個請求需要再規定時間內返回。
2.什麼是雪崩
指分佈式系統中經常會出現某個基礎服務不可用造成整個系統不可用的情況, 這種現象被稱爲服務雪崩效應。
離線雪崩時，新數據無法更新，導致隊列堵塞。
在線雪崩時，在線無法提供正常的檢索服務，從外部看整個系統不可用。
因此，通常雪崩都是說的在線架構。
3. 如何形成的在線雪崩
離線雪崩時，新數據無法更新，導致隊列堵塞。
在線雪崩時，在線無法提供正常的檢索服務，從外部看整個系統不可用。
因此，通常雪崩都是說的在線架構。
在線請求需要在規定時間內返回結果，通常上游對下游的超時時間會設置稍大一些考慮到下游模塊可能需要重試。
下面的圖，大致演示了在線架構雪崩，如果底層模塊出問題，大量請求爲返回，可能導致多個模塊對下游的重試，導致最終下游模塊由於請求量過大系統不可用。
導致雪崩的情況可能有：
- 容量不足。(請求量正常增加)
- 冗餘不足。(無法應對高峯、切流量)
- 熱點數據訪問，導致後端存儲無法及時返回。
- 代碼bug。死循環等。
4. 如何避免
大部分都是套路，除了因爲代碼bug。
大致套路，
- 增加緩存。根據業務需要增加。有些服務必須實時數據就不可加。
- 增加容量。系統需要有一定冗餘度。
- 定時壓測。瞭解當前系統可接受的最大請求壓力。
- 增加有效的監控報警。
- 增加降級策略。臨近雪崩時，模塊自動丟失部分請求；重試次數減少。
參考:
(1) https://segmentfault.com/a/1190000005988895
(2) https://blog.csdn.net/starryninglong/article/details/65628337