流控相關

https://segmentfault.com/a/1190000010237714

http://jm.taobao.org/2018/01/22/post20180122/

對系統的訪問速率，資源佔用，消費者併發鏈接數，並行訪問數 進行限制，在請求量超過閾值時，經過拒絕等方式，防止服務接口的雪崩和掛掉

同步RPC類調用，針對服務提供者的併發全局流控，或針對服務消費者的併發局部流控 

異步MQ類調用，在訂閱端限流，針對消息訂閱者的併發流控，或針對消息訂閱者的消費延時流控。

單機流控  -> 全局流控  -> 動態流控

1. 全局計數器的存儲 redis

     記錄兩個信息，計數和記間， 由於限制通常是多少請求每秒之類的，過時重置

2. 如何上報請求

    全量、定時批量上報

    通常還須要每臺機器部署agent來完成上報和流控判斷，業務模塊和agent之間也要通信

1）將流控服務作成原子化，目前不管使用redis仍是ckv，加鎖方式併發下沒法保證性能，原生的incr方式要解決過時時間的問題，須要的技術門檻和開發成本都比較高；

2）從上報統計方式看，全量上報對請求量巨大的業務部門來講不大可行，定時批量上報又沒法保證明時流控；

3）接入全局流控每臺機器都須要部署agent，agent可否正常工做影響全局流控的使用，同時部署及運維的成本不低；

QPS ， 併發線程數 ， 黑白名單 ， 加權分級 

令牌桶控制的是一個時間窗口內的經過的數據量，在 API 層面咱們常說的 QPS、TPS，正好是一個時間窗口內的請求量或者事務量，只不過期間窗口限定在 1s 罷了。

RateLimiter 對簡單的令牌桶算法作了一些工程上的優化，具體的實現是 SmoothBursty。須要注意的是，RateLimiter 的另外一個實現 SmoothWarmingUp，就不是令牌桶了，而是漏桶算法。也許是出於簡單起見，RateLimiter 中的時間窗口能且僅能爲 1s，若是想搞其餘時間單位的限流，只能另外造輪子。

http://www.liuhaihua.cn/archives/529035.html

配額拉取的概念，替換通常統計上報的方式，取而代之的是每一個key初始化時寫入流控閾值，每一個業務機器並不是上報請求量，而是訪問ckv拉取配額到本地保存，本地配額消耗完畢再次拉取，相似餘庫存扣減。

agent要完成的功能比較簡單，主要功能託管到業務流控api。好比拉取配額設置10，即正常10個請求要拉取一次配額，這時流控api會請求一次ckv拉取配額，這個業務請求耗時增長約1ms。

方案對容災作了充分的考慮，主要解決方式是全局及單機流控同時啓用，即基於ckv的全局流控和基於單機共享內存的單機流控都同時工做。

全局流控失效（ckv掛掉或連續超時致使拉取配額失敗），流控api判斷出這種狀況後，暫時中止使用全局流控，而單機流控依然能夠正常工做，流控api按期去探查（好比30s）全局流控是否恢復可用，再啓動全局流控。

因爲使用ckv的incr以及配額拉取的實現方式，全局流控接入服務請求的能力獲得成本增加。

目前方案單獨申請了一塊ckv，容量爲6G，使用incr的方式，壓測性能達到9w+/s。

對業務空接口（Appplatform框架）作流控壓測，使用30臺v6虛擬機，單機50進程，壓測性能達到50w+/s。

單接口50w/s的請求的服務接入，一樣也能知足多接口整體服務請求量50w+/s的全局流控需求。

上述的壓測瓶頸主要是Appplatform框架的性能緣由，因爲拉取配額值是根據流控閾值設定（通常>10），50w+的請求量只有不到5w的ckv訪問量，ckv沒到瓶頸。

支持平行擴展流控能力，一套全局流控部署能知足流控的服務請求量是達百萬/s，更大的服務請求量須要部署多套全局流控。

支持升級到動態流控能力，ckv寫入的流控閾值是經過定時管理器完成，目前業務已經作了健康度上報，定時管理器只須要對接健康度數據，分析接口當前請求狀況，動態調整流控閾值便可達到動態流控能力。

一、管理定時器：

根據配置，將頻率限制任務的配額值，寫入多個帶時間信息的key。好比頻率限制任務1配了閾值爲5000/s的全局流控，那麼就以每一秒生成一個kv爲例：

key爲task1_20170617000000、task1_2017061700000一、task1_20170617000002等

value爲5000

二、共享內存：

保存每個任務流控相關的本機信息，包括流控狀態、本地配額、配額鎖等。

三、流控API：

業務經過流控api，請求先扣減本地配額（原子操做），若是配額<=0，就從ckv拉取配額到共享內存中，若是沒配額拉取，就作說明流控生效。

 具體，除了上述，在本地配額將滿時候提早拉取必定配額，在即將用盡時增長几率失敗等，在基於@註解定義類加載檢查方式拉取配額，基於dubbo filter擴展方式