Grab熔斷器設計：如何應對突發打車峯值

在東南亞，一旦下雨每每就不小。它成爲一個重要的情緒因素，尤爲是當你被困在外面的時候，你就會面臨糟糕的一天。程序員

在 Grab 的早期，若是雨來的時間不對，好比上班早高峯時間，那麼咱們這些工程師那一天也很差過。算法

在那個時候，Grab 叫車服務的需求增加速度遠超咱們的技術系統擴展能力，咱們常常要加班到深夜，以確保系統可以處理不斷增加的請求。當打車預訂量忽然激增時，咱們的系統仍是難以承載。安全

此外，還有其餘因素致使了需求激增，例如，當公共交通服務出現故障，或者當大型活動如國際音樂會結束，全部的遊客須要同時乘車。網絡

通過思考，咱們發現這些突發事件背後有兩個方面的因素。架構

第一，這些事件都是局部事件。需求的增長來自於一個特定的地理位置，有時是一個很小的區域。這些局部事件有可能對咱們的系統形成很大的負荷，以致於影響到地理位置之外的其餘用戶的體驗。app

其次，潛在的問題是，這些特定地理區域當時缺少車輛供應。分佈式

在 Grab，咱們的目標一直都是在每一個人須要的時候和地點都能找到合適的司機，但上面這種狀況，原本也是不可能達到的。咱們須要找到一種方法來確保這種局部的需求激增不會影響到咱們知足其餘用戶需求的能力。ide

使用 Spampede 熔斷器

Spampede 熔斷器的靈感來自於咱們以前博客上曾經提過的一個概念--熔斷器。https://engineering.grab.com/designing-resilient-systems-part-1微服務

在軟件中，就如電子產品中同樣，熔斷器的設計是爲了保護系統在面對不利條件下的短路。spa

下面咱們來分析一下。

熔斷器包括兩個關鍵的概念：熔斷和不利條件。

首先，熔斷，在這裏指的是對特定的訂單量可以經過的最小處理量，經過這樣作，減小系統的總體負荷。第二，不利條件，指的是在短期內，在一個小的地理區域內，存在對某項服務大量未完成的請求。基於這兩個概念，咱們設計瞭如下流程。

首先，咱們須要以位置感知的方式跟蹤未分配的請求。爲了作到這一點，咱們使用 Geohash 整數算法對未分配請求的取值位置進行轉換。

轉換後，獲得的值就是一個準確的位置。咱們能夠經過下降精度，將這個位置轉換爲 "桶" 或區域。

這種方法毫不是最好的，固然也不徹底跟當地的地理位置相關，可是它的 CPU 效率很是高，並且不須要經過網絡 API 調用外部資源。

如今咱們能夠跟蹤未分配的請求，咱們須要一種方法讓跟蹤有時間維度相關。畢竟，交通情況、司機位置和乘客需求是不斷變化的。咱們原本能夠實現像滑動窗口總和這樣的精確的東西，可是這樣作會帶來不少的複雜性，並且 CPU 和內存成本也會大大增長。

經過使用 Unix 時間戳，咱們經過直接的公式將當前時間轉換爲 "桶" 的時間。

其中 bs 爲時間桶的大小，單位爲秒數。

經過位置和時間桶的計算，咱們能夠用 Redis 來追蹤未分配的預訂。也可使用其餘的數據存儲軟件，但 Redis 對咱們來講很是熟悉，它也是通過實戰檢驗的。

爲了作到這一點，咱們首先經過結合服務類型、地理位置和時間桶來構建 Redis key。有了這個 key，咱們調用增長計數 INCR 命令，它將存儲在該位置的值遞增，並返回新的值。

若是返回的值是 1，這代表本地調用是這個時間桶的第一個值，而後咱們將進行第二次調用 EXPIRE。將在 Redis 項上設置一個存活時間（TTL），讓數據進行自我清理。

你會注意到，咱們是盲目的調用增量，只在須要的時候再進行第二次 EXPIRE 調用。這種模式比起使用更傳統的、load-check-store 的模式更有效率，也更節省資源。

下一步就是配置了。具體來講，就是設置在熔斷器開啓以前，在特定的位置和時間桶中，能夠存在多少個未分配的預訂量。咱們再次使用 Redis。一樣，使用 Redis 是由於對它至關熟悉。

最後要說明的是，咱們在預訂處理開始前就執行了檢查，強調一下，在調用任何其餘服務以前，咱們就執行了檢查代碼。這個代碼會將地點、時間和所請求的服務與當前配置的 Spampede 設置，以及以前未分配的預訂量進行比較。若是已經達到了最大值，那麼咱們當即中止處理。

這聽起來可能有點刺耳 — 尚未嘗試調用就當即拒絕？但 Spampede 過濾器的設計目的就是爲了防止過分的、局部的需求影響到系統的全部用戶。

做爲一個程序員，讀到這裏，可能會以爲很奇怪，有意把預訂量降下來，這樣會影響業務的發展。

說到底，咱們想要作的只是幫助人們到達他們想要去的地方。這個過程是一個系統安全機制：確保系統健康並可以達成送達乘客這一目標。

若是我不強調一下這是關鍵軟件工程的啓示，是觀察者效應和 CAP 定理的基本目標的結合，那我就失職了。觀察者效應是指爲了觀察一個系統帶來的指令及監控等成本，會對系統自己的運行產生影響。

通常來講，監測和限制的精度或一致性越高，消耗資源成本就越高。

在這種狀況下，咱們有意選擇了最節省資源的方案，用較低的精度來換取更多的吞吐量。

參考閱讀：

本文由高可用架構翻譯，技術原創及架構實踐文章，歡迎經過公衆號菜單「聯繫咱們」進行投稿。