前言:

    python下的celery是啥东西大家应该有了解,是一个异步的任务框架 。话说,  我以前写过一个报警平台的项目,也需要任务的扩展成分布式,当时总是觉得 用celery不是那么太靠谱,所以就自己写了一个分布式的任务派发的系统。 

文章源地址,http://xiaorui.cc/?p=254

今个和朋友聊起了分布式爬虫,这哥们说 任务有时候经常的崩溃,但是celery的retry的机制有些意思,最后看了下文档  ,又研究了下retry的参数,然后把自己的一些实战分享给大家。

其实最主要就那几个参数,官网写的也很干练,上来就给个例子。  呵呵 ~ 

bind=True 是开启

max_retries 是重新尝试的此时

default_retry_delay 是默认的间隔时间,尝试的时间

下面的代码,大家应该懂的。  就是捕捉异常。  

countdown 也是时间,这个时间优先级是大于上面的default_retry_delay的。 

wKiom1QFykOCq-JIAADh1XYHEAs045.jpg

这个时候我是可以看到,我刚才设置的,碰到异常之后,重新执行三遍的。 


注意下,这个异常是我自己特意抛出去的,不懂的看上面的py。  还有一点是celery 自己会sleep 时间。  我定义了60s 。 

wKioL1QFzLfDAJRpAAyb981Zi7w970.jpg

然后咱们在测试下,重启celery,任务肯定是正常运行的,毕竟是放在队列里面的。启动celery的时候,他也只是从队列里面取任务。 我写入celery的时候,只要保证后端的队列没挂掉就可以了。



其实我更关注的是崩溃的处理,比如 我们的celery已经做了分布式扩展了。 当一个node已经去到任务,但是突然oom了,sx了。 我原本以为celery 借助rabbotmq的ack机制,来处理这样的情况,但是我的测试结果告诉我,celery的retry机制,只是限于本地玩耍。  其实我们就算不用他的retry装饰器,也可以自己写个for循环,然后过滤下异常罢了。


我现在的做法是,每次获取到任务,做事情之前,先要回调一个接口,然后把我要做的事情push过去,然后把做个标示位,说自己正在干,如果10分钟之后,还没有把你删掉的话,你就再塞入队列中。 

 

当然方法还是有些挫,但是已经线上跑了一段时间,没什么大问题,只是在任务太多的情况下,监控任务的线程貌似多到崩溃。 后期可以改用gevent pool的方式来进行轮训监控事件是否完成。 

如果你是那种平台性质的任务发布,在页面上长时间是loading….的状态,你容易做出分析的。 


但大家没这么倒霉的~  只要异常处理的好。  


个人还是自己开发的靠谱点。 celery可能是太强大了,忽略了一些地方。 



对Python及运维开发感兴趣的朋友可以加QQ群 : 478476595 !!!
{ 2000人qq大群内有各厂大牛,常组织线上分享及沙龙,对高性能及分布式场景感兴趣同学欢迎加入该QQ群 }

另外如果大家觉得文章对你有些作用!   帮忙点击广告. 一来能刺激我写博客的欲望,二来好维护云主机的费用.
如果想赏钱,可以用微信扫描下面的二维码. 另外再次标注博客原地址  xiaorui.cc  ……   感谢!
暂无相关产品