码迷,mamicode.com
首页 > 编程语言 > 详细

python使用异步任务celery出现异常崩溃时retry重试

时间:2014-09-03 02:42:47      阅读:1943      评论:0      收藏:0      [点我收藏+]

标签:celery 异常   celery retry   python celery   


前言:


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


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



#xiaorui.cc
@celery.task(bind=True,max_retries=3,default_retry_delay=1 * 6)
def sum(self, num):
    try:
        f = open(‘plog‘,‘a‘)
        f.write(‘retry\n‘)
        f.close()
        num = num + 1
        return num
    except Exception as exc:
        raise self.retry(exc=exc, countdown=60)

 


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


bind=True 是开启

max_retries 是重新尝试的此时

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


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

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


bubuko.com,布布扣


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


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


bubuko.com,布布扣



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

redis 127.0.0.1:6379> lrange celery 0 -1
1) "{\"body\": \"gAJ9cQEoVQdleHBpcmVzcQJOVQN1dGNxA4hVBGFyZ3NxBFUEaXAgYXEFhXEGVQVjaG9yZHEHTlUJY2FsbGJhY2tzcQhOVQhlcnJiYWNrc3EJTlUHdGFza3NldHEKTlUCaWRxC1UkYTZkMTJkZTMtYjUzOC00ZjMxLWFiNzMtNjExNTQwYjY5NmZkcQxVB3JldHJpZXNxDUsDVQR0YXNrcQ5VCXRhc2tzLnN1bXEPVQl0aW1lbGltaXRxEE5OhnERVQNldGFxElUgMjAxNC0wOS0wMlQxMjoxMjozOC4wNDE4OTYrMDA6MDBxE1UGa3dhcmdzcRR9cRV1Lg==\", \"headers\": {\"redelivered\": true}, \"content-type\": \"application/x-python-serialize\", \"properties\": {\"body_encoding\": \"base64\", \"delivery_info\": {\"priority\": 0, \"routing_key\": \"celery\", \"exchange\": \"celery\"}, \"delivery_mode\": 2, \"correlation_id\": \"a6d12de3-b538-4f31-ab73-611540b696fd\", \"reply_to\": \"4459d9e6-2cff-35c9-be5b-45a2d976911e\", \"delivery_tag\": \"bd4480dd-d04a-4401-876b-831b30b55f4e\"}, \"content-encoding\": \"binary\"}"
2) "{\"body\": \"gAJ9cQEoVQdleHBpcmVzcQJOVQN1dGNxA4hVBGFyZ3NxBFUEaXAgYXEFhXEGVQVjaG9yZHEHTlUJY2FsbGJhY2tzcQhOVQhlcnJiYWNrc3EJTlUHdGFza3NldHEKTlUCaWRxC1UkNDczMzFhYTgtNzZhOC00N2E1LTg1MGItNzZkYTY0YjY2YzM1cQxVB3JldHJpZXNxDUsBVQR0YXNrcQ5VCXRhc2tzLnN1bXEPVQl0aW1lbGltaXRxEE5OhnERVQNldGFxElUgMjAxNC0wOS0wMlQxMjoxMjo1NS40NjA0MzArMDA6MDBxE1UGa3dhcmdzcRR9cRV1Lg==\", \"headers\": {\"redelivered\": true}, \"content-type\": \"application/x-python-serialize\", \"properties\": {\"body_encoding\": \"base64\", \"delivery_info\": {\"priority\": 0, \"routing_key\": \"celery\", \"exchange\": \"celery\"}, \"delivery_mode\": 2, \"correlation_id\": \"47331aa8-76a8-47a5-850b-76da64b66c35\", \"reply_to\": \"4459d9e6-2cff-35c9-be5b-45a2d976911e\", \"delivery_tag\": \"9fa3c120-0bfd-4453-9539-1465e6e820ff\"}, \"content-encoding\": \"binary\"}"
redis 127.0.0.1:6379>



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


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

 

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


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


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


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


本文出自 “峰云,就她了。” 博客,谢绝转载!

python使用异步任务celery出现异常崩溃时retry重试

标签:celery 异常   celery retry   python celery   

原文地址:http://rfyiamcool.blog.51cto.com/1030776/1548051

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!