发包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形成的任务发送到不同的队列中（这样好看点）
面向搜索引擎编程，找到了解决方法
待续
