发包QPS控制，有两个难点。
- redis交互流量的限制。
假设每分钟有1000条流量任务生成，每条跑20个插件，每个插件发5个数据包，每分钟约发十万请求。那么在发包处做QPS会遇到一个问题，如果每次发包时先问一下redis “这条流量在不在QPS限定范围内？如果在，这一秒这一分钟的QPS是否已经达到上限不能发送了？如果没达到我就发送顺便redis这个域名当前秒发送量也+1”，至少每分钟与redis交互十万次以上，估计一下redis的kbps约提升10M以上。
之后会发现，该redis流量过大阻塞集群，小则影响自己的业务，多则影响了别人的集群，DBA夺命报警连环call。
应对：1) 不在发包处做QPS控制，再往上游控制 2）如果该链接对应的业务没有QPS控制需求，就没必要限制也没必要交互了。
- 睡眠
当QPS超过限制的时候，怎么做？首先一般的选择是睡眠。
当一个业务的QPS极低而待扫描的流量又极大时，可能会导致所有节点所有worker都因为该业务的流量正在睡眠中，像幼儿园整个年级都躺在睡眠室里一样其乐融融，因为该业务的QPS限制都在等待中运行不动了。
应对：1) 选择少量节点让其随便睡，再在最上游流量去重处做对应规则。 2）超过QPS的流量就丢弃。
最终实验的方案：
流量将通过celery发送到worker时，根据流量业务的不同，将需调控的流量发送到另外的celery任务队列中。挑选少量节点专门用来执行该队列（需qps控制）的任务。
在调用func.delay时需要根据流量区别，将流量和同一func形成的任务发送到不同的队列中（这样好看点）
面向搜索引擎编程，找到了解决方法
Celery 任务分多队列运行
待续
celery任务分多队列运行
原文：https://www.cnblogs.com/huim/p/11055164.html
