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

待续

05-21 08:40