Celery周期抓取数据
用Python Django做了一个网站。后端有些周期抓数据的需求，分布式任务队列Celery派上了用场。
投入使用后，发现一个问题，运行一段时间后，周期更新的数据刷新时间停留在几天之前，Celery任务莫名其妙就不起作用了。查看日志，Celery beat日志是按周期在更新，但Celery worker日志停留在几天之前。查看进程，beat、worker进程均运行良好。一头雾水。每次碰到这种情况，只能重启。然后过一段时间又不起作用了，断断续续困扰大半年时间。
曾经也暗骂python轮子咋这样不靠谱，甚至也想转投java的怀抱，用spring boot搞一下。略一思考，转投java也有切换成本，换过去之后，也会碰到这样那样的问题。如果这个技术栈上碰到问题解决不了，换个技术栈碰到问题可能还是束手无策。换到java的好处可能是使用广泛，有问题都是别人已经趟过的坑，容易找到借鉴经验。小众的技术栈就没这么好的待遇了。
那么，想办法解决问题吧。
死锁导致Celery worker卡住无法消费新任务
在google多番搜索，有一些线索可供参考。其中一个是说psycopg2、与postgres使用时可能会死锁。原因是postgres使用ssl时在一个callback中加了个锁，但是个callback是共用的，postgres自己unload时会释放这个锁，但是其他使用这个callback的并不知道，然后就死锁了。解决方案是把psycopg2升级到2.6版本以上。
具体可以参考Media上这篇文章。https://medium.com/squad-engineering/two-years-with-celery-in-production-bug-fix-edition-22238669601d
但是我的版本已经是2.8了。所以这个解决方案并不能完全适用于我的问题。不过死锁还是给了我启发。可能celery worker执行某个任务时卡死了。
沿着这个线索继续探索吧。
查看死锁原因
OK，查死锁，下面进入debug阶段。
[root@nfvbfqi9 mysite]# celery inspect active
-> celery@nfvbfqi9: OK
* {'id': '38765e0a-b752-4582-9b3e-cf2ea5cf0c4c', 'name': 'stockinfo.tasks.update_concept_task', 'args': '()', 'kwargs': '{}', 'type': 'stockinfo.tasks.update_concept_task', 'hostname': 'celery@nfvbfqi9', 'time_start': 1566133200.1085725, 'acknowledged': True, 'delivery_info': {'exchange': '', 'routing_key': 'celery', 'priority': 0, 'redelivered': False}, 'worker_pid': 2939}
* {'id': '7cf4a044-bf15-4fc8-a168-c552b393a87b', 'name': 'stockinfo.tasks.clear_django_sessions', 'args': '()', 'kwargs': '{}', 'type': 'stockinfo.tasks.clear_django_sessions', 'hostname': 'celery@nfvbfqi9', 'time_start': 1566252300.1116867, 'acknowledged': True, 'delivery_info': {'exchange': '', 'routing_key': 'celery', 'priority': 0, 'redelivered': False}, 'worker_pid': 2940}
看得出来有2个任务是active状态，但是把timestamp转化一下，是2天之前了。这2个任务不可能要运行这么长时间的。那么肯定是卡住了。
Media文章里用的strace看卡哪了，嗯，可以效仿。一试，我的vps并没安装这个命令对应的库。好吗，毕竟买的廉价低配版，不增加负担。不就是要打印调用栈么，用cat /proc/{pid}/stack。
[root@nfvbfqi9 mysite]# cat /proc/2939/stack
[<ffffffff8144b9b9>] sk_wait_data+0xd9/0xe0
[<ffffffff814a422b>] tcp_recvmsg+0x2cb/0xe80
[<ffffffff814c58ca>] inet_recvmsg+0x5a/0x90
[<ffffffff81449ab3>] sock_recvmsg+0x133/0x160
[<ffffffff81449c2e>] sys_recvfrom+0xee/0x180
[<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
[root@nfvbfqi9 mysite]# cat /proc/2940/stack
[<ffffffff811939cb>] pipe_wait+0x5b/0x80
[<ffffffff81194476>] pipe_read+0x3e6/0x4e0
[<ffffffff81188dba>] do_sync_read+0xfa/0x140
[<ffffffff811896a5>] vfs_read+0xb5/0x1a0
[<ffffffff811897e1>] sys_read+0x51/0x90
[<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
可以看得出来，一个卡在了tcp wait recv_msg上了。一个卡在了pipe_wait上了。2个任务都卡在了IO等待上。
这2个应该都不是死锁，抓取数据tcp请求不可能会死锁的，还是应该要设置超时时间。至于pipe，可能生产者意外退出，导致消费者拿不到数据而一直死等。
解决方案
IO相关操作设置超时时间。
