請你談談爲何分佈式系統須要限流器

什麼是限流器？

限流器是一種限制某種操做在必定時間內的執行次數（例如每秒鐘5次）或者執行量（例如每秒鐘1G大小的數據）的機制。

限流器是一種防護性的編程實現方式，在大數據量高併發訪問時，常常會出現服務或接口面對暴漲的請求而不可用的狀況，甚至引起連鎖反映致使整個系統崩潰。此時你須要使用的技術手段之一就是限流，當請求達到必定的併發數或速率，就進行等待、排隊、降級、拒絕服務等。

爲何須要限流器

在一個大型的分佈式系統，系統設計要考慮不少不少方面：

1. 系統動態擴容縮容，總會有滯後性。業務總會有高峯有低谷。集羣大小不會一直按照高峯的時候的規模運行，這樣成本過高了，通常會有動態擴容策略。可是這種動態擴容，通常是有滯後性的，不能保證瞬時高流量處理的很好。經過限流器，保證某個業務流量到來時，不會覺得這個業務致使其餘業務也沒法正常工做。
2. 級聯故障（cascading failure）：分佈式系統通常會有健康檢查，也通常會有斷路降級機制，流量高峯到來的時候，當某個節點過載，致使這個節點健康檢查失敗下線，或者斷路器打開，致使這個節點的流量打入了其餘節點致使其餘節點也過載。
3. 對於一個公共服務，不一樣租戶或者不一樣用戶都須要限流防止某個用戶將全部的資源都搶光。
4. 流控：爲了防止某一個節點負載特別高，可是其餘節點負載較低。除了經過負載均衡控制外，還須要限流器保證某個節點不會壓力太高。

舉一個簡單的例子：假設一個商城，有下單和查看本身的訂單這兩個業務。限量秒殺的時候，用戶下單量在某一時候忽然飈高。系統目前容量可能不夠承擔這麼大的併發下單量，致使請求阻塞，排隊，並進而致使全部的資源都被下單請求吃掉，用戶查看本身訂單的請求也沒法執行或者很慢。同時，用戶請求刷不出來就會不斷地刷，致使進一步請求堆積。

限流器的相關策略設計

若是徹底不採用限流器，通常須要經過設置適當的請求超時，儘可能小的同步等待隊列和合適的斷路策略，來防止過載。可是，這種方式並不能避免上面說的4個問題。

在目前的微服務體系中，通常一個進程既是服務提供方，又是服務調用方。在服務網格下更是如此。對於服務提供方，限流主要是控制外部流量防止壓力過大。對於服務調用的時候限流，主要是考慮壓力均勻（雖然服務調用通常有負載均衡算法，可是通常的負載均衡算法無法保證真正的負載徹底均衡，客戶端限流器能夠進一步幫助防止壓力所有打到了某一個實例）。

對於服務端限流，當觸發限流的時候，服務端通常會拒絕請求，而且可能返回 429 這個 HTTP 狀態碼。客戶端是這個請求直接異常，仍是緩存起來以後繼續重試，取決於客戶端的策略。

每日一刷，輕鬆提高技術，斬獲各類offer：