扫描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 任务分多队列运行

待续

巴特西

扫描QPS控制——celery任务分多队列运行

1. redis交互流量的限制。

应对：

2. 睡眠

应对：

3. 最终实验的方案：

最新文章

热门文章