作者 | Rafal Gancarz
譯者 | Sambodhi
策劃 | Tina
Monzo 已經開發了一種解決方案，用於應對其平台突然而強烈的流量負擔，以防止服務中斷。這種流量高峰可能是由移動應用引發的，例如推送通知或用戶活動的突發增加。這一解決方案能夠在幾乎不影響客戶體驗的前提下，將讀取流量減少近 50%，整體準確率高達 90%。
Monzo 銀行平台擁有數百萬用戶，他們主要通過移動應用程式與平台互動。然而，有時流量激增可能會使平台陷入不穩定狀態。這可能是由於向大量用戶發送定期的推送通知或特定時間的功能，比如「提前獲得薪水」。儘管 Monzo 團隊已經採取了積極的擴展措施來確保平台具備足夠的容量來處理 「提前獲得薪水」 等事件，但突如其來的流量激增仍然構成重大風險。
Monzo 的高級工程師 Jacob Moxham 解釋了為什麼驚群效應（類似於「驚群問題」）對於 Monzo 平台的穩定性非常危險：
驚群效應是我們用來描述大量客戶在非常短的時間內打開應用程式的情況。如果我們沒有為這些時刻做好準備，我們可能會用盡緩衝容量，無法迅速擴展我們的平台。在最糟糕的情況下，共享基礎設施可能會超負荷，導致廣泛的中斷。
驚群效應是我們用來描述大量客戶在非常短的時間內打開應用程式的情況。如果我們沒有為這些時刻做好準備，我們可能會用盡緩衝容量，無法迅速擴展我們的平台。在最糟糕的情況下，共享基礎設施可能會超負荷，導致廣泛的中斷。
問題被放大，因為 Monzo 應用在打開或接收到推送通知時會預取數據，以確保立即提供最新信息。團隊懷疑大多數這些請求只會返回相同的數據。在為 0.1% 的用戶部署額外的日誌記錄到邊緣代理後，日誌顯示在 24 小時內大約有 70% 的請求返回相同的數據。
為了消除「浪費」的請求，工程師首先選擇創建一個「更改 API」，該 API 將返回最常用和昂貴的終端的最後更新時間。移動應用程式將查詢新的更改 API，並僅在自上次調用以來數據已更改時才請求數據。這種方法在提供準確的最後更新時間戳方面遇到困難，因為常規 API 終端中實施了實時數據增強，並且對 API 資源的更新存在複雜的數據流程。
邊緣代理中的請求削峰邏輯 。（來源 ：Monzo Technology Blog）
相反，團隊得出結論，與其實施完美且永久的解決方案，他們可以創建一個足夠但成本更低的解決方案，只在平台出現嚴重和意外負荷時激活它。他們確定了三個特徵來幫助確定是否削減請求：響應計算的時間，數據預取的觸發器以及在進行請求時移動應用程式打開的時間。
對於第一個特徵，工程師重新利用了 API 終端返回的 Etag HTTP 標頭，其中包含響應哈希和上次計算的時間。在預取數據時，移動應用程式將發送包含與相同請求的先前返回的 Etag 標頭的值以及自定義標頭中的其他兩個特徵的 If-None-Match HTTP 標頭。基於標頭中的元數據，邊緣代理中部署的負載削減策略將確定是否忽略請求並返回 304（未修改）狀態碼或返回計算的響應。不同的預取觸發器的策略可以分別激活，使團隊逐步減少移動應用程式流量的各個部分。
啟用請求削峰後的流量減少。（來源：Monzo Technology Blog）
團隊通過在陰影模式下部署新的策略進行試驗，即計算響應並根據請求元數據與實際結果進行比較來決定是否削減請求。當所有策略都激活時，平台能夠在整體準確率達到 90% 的情況下，減少近 50% 的 GET 請求。工程師報告稱，客戶體驗沒有明顯變化，與可能影響整個平台的主要故障相比，允許一小部分用戶看到陳舊數據是可以接受的。
作者簡介：
Rafal Gancarz，一位經驗豐富的技術領袖和專家，正致力於將 Starbucks 的商業平台打造成可擴展、韌性十足且成本效益顯著的典範。在此之前，他曾參與設計和構建了眾多大規模、分布式和基於雲的系統，為 Cisco、Accenture、Capita、ICE、Callsign 等知名企業貢獻了力量。他的研究領域涵蓋架構與設計、持續交付、可觀測性和可操作性，以及軟體交付的社會技術和組織方面。
原文連結：
https://www.infoq.com/news/2023/10/Nvidia-matx-cpp-numerical-lib/
瘋狂馬斯克的「極限」計劃居然成功了？！「下雲」後成本降低 60%，部分功能代碼精簡 90%，30 天急速遷移伺服器
程式設計師篡改 ETC 餘額，一年私吞 260 余萬元；語雀公布故障原因及賠償方案；各家財報發布，創始人們：就很難受｜Q資訊
可部署手機、適配國產芯……全新升級後的 ChatGLM3 真的有點東西：智譜 AI 選擇繼續開源！
「這是一件關於雲服務的大事兒！」英特爾 4400 萬美元投資基礎設施初創公司，硬剛公有雲