Reddit是如何解決三個臭皮匠的快取首次更新問題？

三個臭皮匠是一個鬧劇喜劇三重奏，他們經常嘗試在簡單的日常任務上進行協作，但最終總是妨礙對方並傷害對方。一個場景：他們一起試圖穿過一個門口。但是因為他們試圖同時並肩穿過，他們撞到了對方；最終，沒有人能夠透過。Reddit 也遇到過透過分散式微服務架構推送請求的類似模式。

 

問題
在 Reddit，我們在從中斷中恢復時遇到了一個有趣的規模問題。我們在微服務上游的 API 閘道器級別有一個響應快取；和快取的響應有一個 TTL。現在假設該站點停機的時間比 TTL 長，因此快取已被重新整理清零。
當站點恢復時，我們會收到大量請求 其中許多是重複請求同一個資源，都是在短時間內發生的。在正常操作期間，大多數這些重複請求將從快取中提供服務。但是當從這樣的中斷中恢復時，因為沒有快取任何東西，所有重複的請求都會同時命中我們的微服務、底層資料庫和搜尋引擎。這會導致流量氾濫，以至於在請求超時內沒有任何請求成功，因此沒也有響應被快取；並且該站點會立即再次進行修復。
我們將這種情況稱為“三個臭皮匠問題”，儘管它更常被稱為“雷霆萬鈞Thundering Herd”、 “狗堆效應”或“快取踩踏事件”。
 

解決方案
我們對三個臭皮匠問題的解決方案是在微服務級別對請求進行重複資料刪除和快取響應。請求重複資料刪除（也稱為請求摺疊或請求合併）意味著重新排序重複的請求，以便它們一次執行一個。此解決方案有效的原因是，從概念上講，它對請求重新排序，以便從不重複併發執行，甚至不在不同的後端例項上（分散式鎖強制執行此操作）。然後第一個請求被處理並且它的響應被快取。然後，該請求的所有後續重複項將被序列執行並從快取中得到滿足。這使我們能夠更有效地利用我們的快取，併為我們節省了底層資料庫和搜尋引擎上重複請求的負載。
將重複資料刪除/快取移至其堆疊中的不同點——特別是其微服務級別——以及“一個可以處理許多併發請求的網路堆疊”。然後工程師只需實現程式碼，確保不會無意中同時處理兩個重複項（使用分散式鎖）。剩下的就是檢查已經檢索到的響應是否存在，如果沒有找到快取的響應，則只建立新的響應。
將重複資料刪除視為迫使 三個臭皮匠在通往廚房的門口排成一條有秩序的隊伍。然後第一個臭皮匠進了廚房，拿著一碗扁豆湯離開，那碗湯就被收起來了。然後另外兩個臭皮匠得到了快取的碗湯。
 
Reddit 的 API 閘道器將來自不同平臺的所有傳入請求整理成標準形式，以便於處理（同時丟棄任何不相關的多餘變數）。但是，當它們達到微服務級別時，重複資料刪除最終會使用一種稱為雜湊表的簡單程式設計結構來處理——其中一個值與一個可以在以後檢索它的唯一識別符號（一個鍵）配對。這建立了一種發現重複值的簡單方法，因為它們已經被分配了一個識別符號。
Reddit 提供了一個示例中的程式碼片段，其中使用 Pottery 的Redis Redlock實現來實現分散式鎖。GitHub 儲存庫中，
重要的是，分散式鎖具有自動釋放超時以保持活性。想象一個執行緒獲取鎖然後在臨界區死亡的情況。如果沒有自動釋放超時，鎖將永遠不會被釋放，從而導致死鎖。
解決三個臭皮匠問題的最後一個構建塊是快取響應結果。同樣，我們可以實現一個裝飾器來包裝端點函式來快取響應，它使用請求雜湊作為快取鍵。它嘗試查詢該快取鍵，並在命中時返回快取的響應。如果未命中，它會呼叫底層端點函式，快取後續重複請求的響應，然後返回計算出的響應。
 

問答

• 為什麼不在 CDN 或邊緣而是在微服務級別對請求和快取響應進行重複資料刪除？

• 在請求重複資料刪除期間，如果您的底層基礎架構出現問題並且分散式鎖自動超時，會發生什麼情況？

• 為什麼不在您的微服務中更深入地刪除重複的函式呼叫和快取函式返回值？