摘要：二現(xiàn)有方案分析目前全局流控方案主要需要解決兩個(gè)實(shí)現(xiàn)問(wèn)題全局計(jì)數(shù)器使用何種存儲(chǔ)全局計(jì)數(shù)器存儲(chǔ)可以使用，也可以使用。優(yōu)勢(shì)方案減少的訪問(wèn)量，同時(shí)保證流控的準(zhǔn)確性。

作者：莫家文，騰訊事務(wù)型開(kāi)發(fā)工程師

商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系騰訊WeTest獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。

原文鏈接：http://wetest.qq.com/lab/view/320.html

全新的全局流控實(shí)現(xiàn)方案，既解決了目前流控的實(shí)現(xiàn)難點(diǎn)，同時(shí)保證運(yùn)行穩(wěn)定且流控準(zhǔn)確的前提下，實(shí)現(xiàn)更簡(jiǎn)單，部署成本更低，容災(zāi)能力更強(qiáng)。 該方案組件化之后，可以推廣到別的有需要的部門使用，只需簡(jiǎn)單的接入和部署即可獲得全局流控的能力。

流控作為容災(zāi)體系中必不可少的一環(huán)，在請(qǐng)求量超過(guò)系統(tǒng)容量的時(shí)候，通過(guò)拒絕超量請(qǐng)求的方式，防止服務(wù)接口的雪崩和系統(tǒng)掛掉。

目前部門只具備單機(jī)流控的能力，隨著業(yè)務(wù)的增長(zhǎng)和系統(tǒng)復(fù)雜度的增加，單機(jī)流控越來(lái)越不能滿足需要，升級(jí)流控能力日趨重要。

升級(jí)流控之前，先簡(jiǎn)單了解不同流控方式的優(yōu)缺點(diǎn)：

對(duì)比可知，全局流控能能彌補(bǔ)單機(jī)流控的缺點(diǎn)，而動(dòng)態(tài)流控又是在全局流控的基礎(chǔ)上做更精細(xì)化的流控。

目前全局流控方案主要需要解決兩個(gè)實(shí)現(xiàn)問(wèn)題：

1、全局計(jì)數(shù)器使用何種存儲(chǔ)

全局計(jì)數(shù)器存儲(chǔ)可以使用redis，也可以使用ckv。

分布式流控很關(guān)鍵一點(diǎn)是將流控服務(wù)做成原子化。而做流控需要記錄兩個(gè)信息，計(jì)數(shù)和計(jì)時(shí)。比如全局流控閾值設(shè)置了5w/s的值，計(jì)數(shù)器記錄了當(dāng)前的請(qǐng)求數(shù)（計(jì)數(shù)），在達(dá)到1s時(shí)計(jì)數(shù)器需失效或清零（計(jì)時(shí)）。

計(jì)數(shù)和計(jì)時(shí)要保證原子操作，目前已知的方式有：

1）使用加鎖的方式，比如ckv的cas計(jì)數(shù)，或者redis+lua技術(shù)，但在并發(fā)量大的時(shí)候，加鎖的性能比較無(wú)法保證；

2）使用incr的方式，由于目前redis和ckv的incr都沒(méi)過(guò)期時(shí)間設(shè)置，要滿足要求（計(jì)數(shù)和計(jì)時(shí)同時(shí)原子操作），需改造redis或ckv，使得incr支持過(guò)期時(shí)間設(shè)置，目前已知有改造redis支持過(guò)期時(shí)間的案例。

2、 如何上報(bào)請(qǐng)求

一般統(tǒng)計(jì)的方式分兩種：

1） 請(qǐng)求全量上報(bào)，這樣要求存儲(chǔ)的訪問(wèn)能力足夠強(qiáng)大，優(yōu)點(diǎn)是流控實(shí)時(shí)性得到保證；

2） 請(qǐng)求定時(shí)批量上報(bào)，這樣存儲(chǔ)的訪問(wèn)壓力較小，資源消耗也更少，缺點(diǎn)是流控可能不實(shí)時(shí)；

一般還需要每臺(tái)機(jī)器部署agent來(lái)完成上報(bào)和流控判斷，業(yè)務(wù)模塊與agent之間要實(shí)現(xiàn)通訊。

大體的邏輯結(jié)構(gòu)如下：

注：圖片來(lái)自文章《MSDK全局流控介紹》

實(shí)現(xiàn)難點(diǎn)：

1）將流控服務(wù)做成原子化，目前無(wú)論使用redis還是ckv，加鎖方式并發(fā)下無(wú)法保證性能，原生的incr方式要解決過(guò)期時(shí)間的問(wèn)題，需要的技術(shù)門檻和開(kāi)發(fā)成本都比較高；

2）從上報(bào)統(tǒng)計(jì)方式看，全量上報(bào)對(duì)請(qǐng)求量巨大的業(yè)務(wù)部門來(lái)說(shuō)不大可行，定時(shí)批量上報(bào)又無(wú)法保證實(shí)時(shí)流控；

3）接入全局流控每臺(tái)機(jī)器都需要部署agent，agent能否正常工作影響全局流控的使用，同時(shí)部署及運(yùn)維的成本不低；

面對(duì)目前困難，我們提出這樣的疑問(wèn)：
有沒(méi)有一套簡(jiǎn)單可行的方案，能解決上述問(wèn)題的同時(shí)，保證開(kāi)發(fā)成本較低，部署簡(jiǎn)單，運(yùn)行穩(wěn)定，而且流控準(zhǔn)確的呢？

方案要點(diǎn)：

1、計(jì)數(shù)器的key能“計(jì)時(shí)“

首先選擇使用ckv作為計(jì)數(shù)器存儲(chǔ)，相比redis開(kāi)發(fā)會(huì)更熟悉，同時(shí)維護(hù)也更容易，當(dāng)然該方案也可以選擇redis作為計(jì)數(shù)器存儲(chǔ)。

既然使用ckv的cas用作計(jì)數(shù)在高并發(fā)下有性能瓶頸，那么只能使用incr的方式，同時(shí)要解決計(jì)時(shí)的問(wèn)題。

方案沒(méi)有對(duì)incr增加過(guò)期時(shí)間的方式，而是將時(shí)間信息寫(xiě)入key，把一天按時(shí)間劃分（比如1s劃分一個(gè)key）為若干個(gè)key作為計(jì)數(shù)器。這樣每個(gè)key既能使用incr方式計(jì)數(shù)，同時(shí)也有”計(jì)時(shí)“的能力，當(dāng)超過(guò)劃分時(shí)間（比如1s后），就順移到下一個(gè)key上做計(jì)數(shù)。

優(yōu)勢(shì)：方案用簡(jiǎn)單的方式將全局流控服務(wù)做成原子化（計(jì)數(shù)和計(jì)時(shí)原子化），開(kāi)發(fā)門檻低。

2、請(qǐng)求統(tǒng)計(jì)用拉取的方式替換上報(bào)

對(duì)于請(qǐng)求的統(tǒng)計(jì)方式，一般全量上報(bào)不可行，所有業(yè)務(wù)的請(qǐng)求量至少1：1上報(bào)到ckv，ckv的容量和是個(gè)問(wèn)題，單key也容易成為熱點(diǎn)。定時(shí)或者定量批量上報(bào)，都無(wú)法保證實(shí)時(shí)流控，特別是請(qǐng)求量大的時(shí)候，流控延遲的問(wèn)題會(huì)被放大。

方案拋開(kāi)原有的上報(bào)思維定式，引入配額拉取的概念，替換一般統(tǒng)計(jì)上報(bào)的方式，取而代之的是每個(gè)key初始化時(shí)寫(xiě)入流控閾值，每個(gè)業(yè)務(wù)機(jī)器并非上報(bào)請(qǐng)求量，而是訪問(wèn)ckv拉取配額到本地保存，本地配額消耗完畢再次拉取，類似余庫(kù)存扣減。

優(yōu)勢(shì)：方案減少ckv的訪問(wèn)量，同時(shí)保證流控的準(zhǔn)確性。

3、部署不需要agent

已有的流控方案都需要每臺(tái)業(yè)務(wù)機(jī)器部署agent，完成上報(bào)請(qǐng)求和流控判斷的功能。這樣做機(jī)器都要部署agent，同時(shí)agent的正常使用也要納入維護(hù)。

為了做更輕量的方案，我們考慮agent的必要性，分析發(fā)現(xiàn)，agent要完成的功能比較簡(jiǎn)單，主要功能托管到業(yè)務(wù)流控api。

這樣的做法會(huì)讓業(yè)務(wù)在調(diào)用流控校驗(yàn)時(shí)有額外的開(kāi)銷，開(kāi)銷主要是拉取配額訪問(wèn)ckv的時(shí)間消耗，正常是<1ms，只要每次拉取配額的值設(shè)置合理，分?jǐn)偟矫總€(gè)請(qǐng)求的耗時(shí)就少的可以忽略。

比如拉取配額設(shè)置10，即正常10個(gè)請(qǐng)求要拉取一次配額，這時(shí)流控api會(huì)請(qǐng)求一次ckv拉取配額，這個(gè)業(yè)務(wù)請(qǐng)求耗時(shí)增加約1ms。

優(yōu)勢(shì)：方案不采用agent的方式，部署維護(hù)更簡(jiǎn)單。

4、全局及單機(jī)流控同時(shí)啟用

考慮全局流控不可用的情況，比如ckv掛掉，能否保證業(yè)務(wù)不受影響且流控可用？

方案對(duì)容災(zāi)做了充分的考慮，主要解決方式是全局及單機(jī)流控同時(shí)啟用，即基于ckv的全局流控和基于單機(jī)共享內(nèi)存的單機(jī)流控都同時(shí)工作。

全局流控失效（ckv掛掉或連續(xù)超時(shí)導(dǎo)致拉取配額失敗），流控api判斷出這種情況后，暫時(shí)停止使用全局流控，而單機(jī)流控依然可以正常工作，流控api定期去探查（比如30s）全局流控是否恢復(fù)可用，再啟動(dòng)全局流控。

優(yōu)勢(shì)：方案有很好的容災(zāi)能力，容災(zāi)方式簡(jiǎn)單有效。

5、解決ckv性能瓶頸，流控性能達(dá)百萬(wàn)/s

由于使用ckv的incr以及配額拉取的實(shí)現(xiàn)方式，全局流控接入服務(wù)請(qǐng)求的能力得到成本增長(zhǎng)。

目前方案多帶帶申請(qǐng)了一塊ckv，容量為6G，使用incr的方式，壓測(cè)性能達(dá)到9w+/s。

對(duì)業(yè)務(wù)空接口（Appplatform框架）做流控壓測(cè)，使用30臺(tái)v6虛擬機(jī)，單機(jī)50進(jìn)程，壓測(cè)性能達(dá)到50w+/s。

單接口50w/s的請(qǐng)求的服務(wù)接入，同樣也能滿足多接口總體服務(wù)請(qǐng)求量50w+/s的全局流控需求。

上述的壓測(cè)瓶頸主要是Appplatform框架的性能原因，由于拉取配額值是根據(jù)流控閾值設(shè)定（一般>10），50w+的請(qǐng)求量只有不到5w的ckv訪問(wèn)量，ckv沒(méi)到瓶頸。

優(yōu)勢(shì)：方案使用同等的資源（多帶帶一塊6G的ckv），能滿足業(yè)務(wù)的請(qǐng)求量更高，性能達(dá)百萬(wàn)/s。

6、支持?jǐn)U容和動(dòng)態(tài)流控升級(jí)

支持平行擴(kuò)展流控能力，一套全局流控部署能滿足流控的服務(wù)請(qǐng)求量是達(dá)百萬(wàn)/s，更大的服務(wù)請(qǐng)求量需要部署多套全局流控。

支持升級(jí)到動(dòng)態(tài)流控能力，ckv寫(xiě)入的流控閾值是通過(guò)定時(shí)管理器完成，目前業(yè)務(wù)已經(jīng)做了健康度上報(bào)，定時(shí)管理器只需要對(duì)接健康度數(shù)據(jù)，分析接口當(dāng)前請(qǐng)求情況，動(dòng)態(tài)調(diào)整流控閾值即可達(dá)到動(dòng)態(tài)流控能力。

優(yōu)勢(shì)：方案整體簡(jiǎn)單輕量，擴(kuò)容和升級(jí)都很容易。

接下來(lái)詳細(xì)介紹一下具體方案的實(shí)現(xiàn)。

方案涉及幾個(gè)功能簡(jiǎn)單、清晰的角色：

1、管理定時(shí)器：

根據(jù)配置，將頻率限制任務(wù)的配額值，寫(xiě)入多個(gè)帶時(shí)間信息的key。比如頻率限制任務(wù)1配了閾值為5000/s的全局流控，那么就以每一秒生成一個(gè)kv為例：

key為task1_20170617000000、task1_20170617000001、task1_20170617000002等

value為5000

2、共享內(nèi)存：

保存每一個(gè)任務(wù)流控相關(guān)的本機(jī)信息，包括流控狀態(tài)、本地配額、配額鎖等。

3、流控API：

業(yè)務(wù)通過(guò)流控api，請(qǐng)求先扣減本地配額（原子操作），如果配額<=0，就從ckv拉取配額到共享內(nèi)存中，如果沒(méi)配額拉取，就做說(shuō)明流控生效。

全局流控過(guò)程可以抽象出三個(gè)主要狀態(tài)：

1、全局非流控狀態(tài)指的是全局流控可用的情況下，但還沒(méi)觸發(fā)限流，業(yè)務(wù)請(qǐng)求可以正常通過(guò)；

2、全局流控狀態(tài)指的是業(yè)務(wù)請(qǐng)求觸發(fā)限流，請(qǐng)求不能通過(guò)；

3、全局失效狀態(tài)指的是全局流控由于異常不可用，比如ckv訪問(wèn)超時(shí)或掛掉，業(yè)務(wù)請(qǐng)求可以正常通過(guò)；

圍繞三個(gè)流控狀態(tài)的跳轉(zhuǎn)，抽象出整個(gè)全局流控的核心關(guān)鍵流程：

1、當(dāng)狀態(tài)為全局非流控，首先會(huì)先扣減本地配額，本地配額<=0時(shí)，就走拉取配額流程；

2、當(dāng)狀態(tài)為全局流控，本地配額<=0時(shí)，先判斷key是否發(fā)生變化，作用是同一個(gè)時(shí)間間隔內(nèi)配額已經(jīng)消耗完，減少無(wú)效的拉取；

3、當(dāng)狀態(tài)為全局失效，會(huì)判斷時(shí)間是否已經(jīng)超過(guò)一個(gè)設(shè)定值，在失效時(shí)間內(nèi)不會(huì)嘗試?yán)∨漕~，作用是減少無(wú)效的拉取；

4、 拉取配額先獲取原子鎖，作用是當(dāng)業(yè)務(wù)進(jìn)程并發(fā)拉取時(shí)，只有獲取鎖成功的進(jìn)程，才能拉取賠額額；

整個(gè)流程考慮了所有會(huì)發(fā)生的情況，圍繞三個(gè)狀態(tài)的跳轉(zhuǎn)，正常及異常流程處理都很好的統(tǒng)一到一個(gè)流程里。

比如發(fā)送ckv不可用的故障，通過(guò)拉取配額失敗的動(dòng)作，很好的從正常的全局非流控狀態(tài)切換到全局失效狀態(tài)，又通過(guò)定時(shí)拉配額，去探查故障是否消除，如果消除就回復(fù)到全局非流控的正常狀態(tài)。

由于以時(shí)間間隔做key，劃分不同的時(shí)間片并寫(xiě)入流控配額，當(dāng)機(jī)器拉取配額面臨個(gè)機(jī)器時(shí)間是否一致的問(wèn)題。

據(jù)了解，時(shí)間同步是通過(guò)ntp服務(wù)來(lái)完成，精度在1~50ms之間，一般情況是<10ms。

目前的時(shí)間間隔都是1s以上，ntp服務(wù)的精度已經(jīng)滿足。

換句話說(shuō)只要保證ntp服務(wù)正常運(yùn)行，全局流控的單個(gè)時(shí)間片的計(jì)數(shù)是準(zhǔn)確的。

如果ntp服務(wù)沒(méi)正運(yùn)行，導(dǎo)致機(jī)器時(shí)間不一致，會(huì)導(dǎo)致同一時(shí)刻應(yīng)該訪問(wèn)同一key的機(jī)器，訪問(wèn)了多個(gè)key，則會(huì)造成計(jì)數(shù)不準(zhǔn)確。

由于ntp服務(wù)目前處理方式是通過(guò)監(jiān)控流控任務(wù)一段時(shí)間內(nèi)的key的變化情況，及時(shí)發(fā)現(xiàn)機(jī)器時(shí)間不一致的情況。具體做法是如果發(fā)現(xiàn)某一時(shí)刻超過(guò)兩個(gè)kv的配額值發(fā)生變化，可以確認(rèn)機(jī)器同一時(shí)刻訪問(wèn)key的分布超過(guò)合理的范圍，有時(shí)間有不一致的情況。

為了保證并發(fā)情況下配計(jì)數(shù)的準(zhǔn)確性，會(huì)使用原子操作的方式處理計(jì)數(shù)，無(wú)需加鎖。

1、全局配額是用ckv的incr方式，保證配額拉取扣減的準(zhǔn)確；

2、本地配額累加或扣減，對(duì)共享內(nèi)存使用gcc提供的__sync_add_and_fetch的原子操作方式；

拉取配額使用了加鎖，鎖的方式是對(duì)對(duì)共享內(nèi)存使用gcc提供__sync_bool_compare_and_swap的原子操作方式。

極端情況下，獲取鎖的進(jìn)程core掉，就會(huì)導(dǎo)致鎖無(wú)法釋放，其他進(jìn)程需要拉取配額時(shí)也獲取不了鎖。死鎖不會(huì)影響業(yè)務(wù)請(qǐng)求正常通過(guò)，但由于無(wú)法拉取配額，會(huì)導(dǎo)致全局流控?zé)o法使用。

處理這種情況目前的方式是，判斷加鎖的時(shí)長(zhǎng)是否超過(guò)合理值 ，具體做法是加鎖記錄當(dāng)前時(shí)間，正常釋放清空這個(gè)時(shí)間值，獲取不了鎖的進(jìn)程判斷加鎖的時(shí)長(zhǎng)，大于設(shè)定值（1min），說(shuō)明有死鎖情況，主動(dòng)釋放鎖。

配額拉取的值的設(shè)置起到一個(gè)很關(guān)鍵的一步，影響流控的準(zhǔn)確性，拉取的效率以及ckv訪問(wèn)壓力。

拉取配額值合理，既減少ckv訪問(wèn)壓力，減輕業(yè)務(wù)Api額外的拉取耗時(shí)（一般<1ms），同時(shí)也能保證流控準(zhǔn)確。

拉取配額值不合理，設(shè)置過(guò)大會(huì)造成機(jī)器剩余的配額浪費(fèi)，需要配額的機(jī)器可能沒(méi)配額，導(dǎo)致產(chǎn)生錯(cuò)誤流控。設(shè)置過(guò)小會(huì)導(dǎo)致本地配額消耗完（本地配額值<0），配額拉取滯后，造成流控生效延后，拉取次數(shù)過(guò)多，ckv訪問(wèn)壓力大，業(yè)務(wù)api拉取效率低。

配額值的設(shè)置是：?jiǎn)螜C(jī)閾值與拉取值的比值為50。比如全局流控閾值 10000/s，機(jī)器數(shù)20，平均單機(jī)流控閾500/s，配額值設(shè)定為10。

目前是通過(guò)壓測(cè)觀察的經(jīng)驗(yàn)值得來(lái)，拉取值設(shè)置是否合理，還有待后續(xù)觀察和分析。

部署：

1、管理定時(shí)器的部署，只需多帶帶部署到腳本機(jī)上；

2、業(yè)務(wù)模塊添加流控api，已經(jīng)接入原來(lái)單機(jī)流控的業(yè)務(wù)，無(wú)需改動(dòng)業(yè)務(wù)邏輯代碼，只需要替換舊的靜態(tài)庫(kù)和依賴的的頭文件即可（待給出詳細(xì)接入）；

擴(kuò)展：

方案支持平行擴(kuò)展，一套全局流控部署能滿足流控的服務(wù)請(qǐng)求量是50w+/s，更大的服務(wù)請(qǐng)求量需要部署多套全局流控。平行擴(kuò)展一套主要的變更包括：申請(qǐng)新的ckv，使用新的一塊共享內(nèi)存以及新的流控任務(wù)配置。

1、對(duì)流控任務(wù)做了可視化監(jiān)控

主要監(jiān)控及跟蹤各流控任務(wù)的基本使用能夠信息，以及當(dāng)前和歷史流量情況

2、機(jī)器時(shí)間不一致的監(jiān)控及上報(bào)

主要監(jiān)控流控任務(wù)一段時(shí)間內(nèi)的key的變化情況，及時(shí)發(fā)現(xiàn)機(jī)器是否時(shí)間不一致

1、管理定時(shí)器接入zk主從切換組件，在單點(diǎn)掛掉的情況下可以切到另外一臺(tái)機(jī)器上，保證timer的可用性。

2、當(dāng)ckv連接超時(shí)或無(wú)法訪問(wèn)時(shí)，對(duì)應(yīng)的流控狀態(tài)會(huì)變成全局失效，過(guò)一段時(shí)間會(huì)自動(dòng)重新拉起。所以出現(xiàn)ckv不可用的情況，只需要恢復(fù)ckv，接入全局流控的服務(wù)會(huì)自動(dòng)恢復(fù)可用狀態(tài)。

目前流控監(jiān)控只是對(duì)流控任務(wù)使用情況做了簡(jiǎn)單的展示，流控的歷史情況等其他必要的信息還沒(méi)能查詢及展示。

還有待補(bǔ)充的監(jiān)控有機(jī)器時(shí)間不一致監(jiān)控，監(jiān)控發(fā)現(xiàn)的問(wèn)題需要告警，以便于人工及時(shí)介入。

有待規(guī)劃的監(jiān)控和告警后續(xù)再補(bǔ)充。

流控升級(jí)下一步是從全局流控升級(jí)到動(dòng)態(tài)流控，所需健康度數(shù)據(jù)已經(jīng)上報(bào)，而接入的方式目前可以直接在管理定時(shí)器上面增加配額調(diào)整的能力，這個(gè)擴(kuò)展很方便。重點(diǎn)應(yīng)該是怎么去根據(jù)上報(bào)的健康數(shù)據(jù)分析并實(shí)現(xiàn)動(dòng)調(diào)整當(dāng)前配額值。

配額調(diào)整大致的思路如下：

注：圖片來(lái)自于理財(cái)通的《接入層限流介紹》

WeTest壓測(cè)大師運(yùn)用了沉淀十多年的內(nèi)部實(shí)踐經(jīng)驗(yàn)總結(jié)，通過(guò)基于真實(shí)業(yè)務(wù)場(chǎng)景和用戶行為進(jìn)行壓力測(cè)試，幫助游戲開(kāi)發(fā)者發(fā)現(xiàn)服務(wù)器端的性能瓶頸，進(jìn)行針對(duì)性的性能調(diào)優(yōu)，降低服務(wù)器采購(gòu)和維護(hù)成本，提高用戶留存和轉(zhuǎn)化率。

功能目前免費(fèi)對(duì)外開(kāi)放中，點(diǎn)擊鏈接：http://wetest.qq.com/gaps 即可體驗(yàn)！

如果對(duì)使用當(dāng)中有任何疑問(wèn)，歡迎聯(lián)系騰訊WeTest企業(yè)qq：800024531