掃描QPS控制——celery任務分多隊列運行

發包QPS控制，有兩個難點。

1. redis交互流量的限制。

假設每分鐘有1000條流量任務生成，每條跑20個插件，每一個插件發5個數據包，每分鐘約發十萬請求。
那麼在發包處作QPS會遇到一個問題，若是每次發包時先問一下redis
「這條流量在不在QPS限定範圍內？若是在，這一秒這一分鐘的QPS是否已經達到上限不能發送了？若是
沒達到我就發送順便redis這個域名當前秒發送量也+1」，
至少每分鐘與redis交互十萬次以上，估計一下redis的kbps約提高10M以上。

以後會發現，該redis流量過大阻塞集羣，小則影響本身的業務，多則影響了別人的集羣，DBA奪命報警連環call。

應對：

1)不在發包處作QPS控制，再往上游控制
2)若是該連接對應的業務沒有QPS控制需求，就不必限制也不必交互了。

2. 睡眠

當QPS超過限制的時候，怎麼作？首先通常的選擇是睡眠。
當一個業務的QPS極低而待掃描的流量又極大時，
可能會致使全部節點全部worker都由於該業務的流量正在睡眠中，
像幼兒園整個年級都躺在睡眠室裏同樣其樂融融，
由於該業務的QPS限制都在等待中運行不動了。

應對：

1)選擇少許節點讓其隨便睡，再在最上游流量去重處作對應規則。
2)超過QPS的流量就丟棄。

3. 最終實驗的方案：

流量將經過celery發送到worker時，根據流量業務的不一樣，將需調控的流量發送到另外的celery任務隊列中。挑選少許節點專門用來執行該隊列（需qps控制）的任務。

在調用func.delay時須要根據流量區別，將流量和同一func造成的任務發送到不一樣的隊列中（這樣好看點）

面向搜索引擎編程，找到了解決方法

Celery 任務分多隊列運行

待續