暴、崩崩、hell hell hell

之前對於特殊酷炫的名詞一向就有紀錄的習慣，今天來講一些聽起來就很猛的 💪

如果有人還有紀錄別的 #風暴、#雪崩 跟 #地獄 拜託跟我講一下 🙏

實務上要不要記看你自己，但有一些面試也是愛問為什麼會這樣，然後要怎麼解就是了 🤔

如果你跟我一樣不太刷題的，這種觀念經驗題就不要錯過了 🎁

不過篇幅的關係，我就不特別再 PO 一次解法的筆記了，有興趣的之後再直接去我的 blog 找。但其實大家用關鍵字去搜尋大概也都有解答 👍

#風暴

Retry Storms

分散式系統中，假設服務調用鍊是 A → B → C → D。

通常無論是 框架 或是 AP 我們都會有 failure 或是 timeout retry 的機制，如果你那些 D 可能因為一些原因無法完全正常的提供服務，那就會開始產生連鎖反應，導致部分或是全部的 C retry，然後因為 C 掛了換 B 也 retry，最後 A 也 retry。

不過更可怕的是重試是有次數的，假設你的 policy 是失敗後重試 r 次，你的 RPS 是 n，你的調用鍊有 m 層，算起來就是 n * r ^ (m-1)。

那一重試起來可是沒完沒了，變成自己打自己，像蝗蟲過境把所有服務打到歪掉。而其實 Retry Storms 也是導致後面要說的 Service Avalanche 的一個狀況。

那你說那就不要 retry 啊 XDD，你說的沒錯，的確是不要亂 retry。但因為合理的 retry 用來解鯊魚咬電纜或是網路抖動 (我盡量不用對岸的詞，但這個詞太可愛了) 是利器。老樣子，剛剛好就好，過猶不及。

#雪崩

其實這兩個都算在分布式系統雪崩裡頭的場景，我們先從小的開始講

Cache Avalanche

這個484聽名字就超酷，但其實挺嚴肅的，如果你的系統流量算高，Cache 用爽爽，王子跟公主過著幸福快樂的日子。

但突然大規模的 Cache 失效，這個失效有可能是因為 Cache 服務不可用或者是 TTL Policy 設定不正確，接著所有的 RPS 就會瞬間往 DB 灌，我們先不管你的 DB 夠不夠壯，但反正可以叫你家那位 DBA 起床尿尿了。

而著名的 Cache 議題還有兩個，叫做 Cache Breakdown、Cache Penetration。

這個問題通常還有一個麻煩的點是，如果不明究理就試圖修復被打掛的 DB 也沒用，一上來又會被海量 RPS 打垮。

Service Avalanche

承剛剛 Retry Storms 那邊說的，如果發生了 Retry Storms 就可能會產生 Service Avalanche，不過其實還有兩種狀況會導致 Service Avalanche。

第一種是服務接收方的不可用，可能是網路也可能是 AP 自己也可能是相依的服務壞掉，最終導致上游調用失敗開始一連串的爆炸。

第二種是服務調用方的不可用，例如 Spring Cloud Ribbon 那種 Client Side Load Balancer。如果 Thread 耗盡就會 GG，上游一樣會炸裂。

#地獄

Callback Hell

這個圖有名到我不知道怎麼解釋，不多說直接上圖。其實這個圖也有 if else 版本。

Dependency Hell

如果你是 Java 的孩紙，大概會知道 Maven 崛起的過程大概跟解了這個難題有一部分的關係。

基本上意思是，A 相依十數個函式庫，這十數個函式庫自己又有相依的函式庫可能有很多層的關係，萬一這棵大樹的節點彼此又有相同的函式庫相依但版本號不同那就會整個很精彩。

基本上用這個來判斷一個語言的成熟性也是一個方法。現在我不太知道，但幾年前 Go 就為了這件事在百家爭鳴，其實我也忘了最後的贏家是誰。

DLL Hell

這個東西我就是只聽前輩講過了，據說是以前 Windows DLL 的管理機制破破的，蓋來蓋去。一不小心就升天。

但若要嚴格的分類的話，其實他跟 Dependency Hell 應該算在同一類。

呼，終於把放了好幾年只筆記丟一邊的東西整理寫出來了，撥雲見日Ｒ👏