记录一次celery消费失败的问题排除

0x00

昨天发完UAT后，今天惯例点进UAT看看服务的情况，突然发现flower监测的celery竟然有半数以上的失败！

开始排查

马上查看这个queue的日志，确实是有一堆失败的。

当前这个queue的业务是从redis里把数据取出来写入minio里落盘，但是涉及的数据均为几十k的数据，讲道理不应该会失败。

查询得到这几个失败的任务redis key的插入时间为2020-12-28 15:17:48，而消费的时间却是2020-12-29 17:17:21

这里就出现了一个问题，业务逻辑上当一个key塞入redis中后，马上会把落盘任务推到队列里，一般来说不会积攒这么久。但是此处竟然积攒到了一天以上才开始消费，而此处也因为我们设置的redis单key最大过期时间为24小时，所以导致落盘任务失败，并且数据丢失了。

发现问题

那么到底是什么任务积攒在队列里积攒了这么久。。？经过和同事分析发现，因为此次发版前还没有上线深度学习的功能，所以只分配了两个通用消费者。当启动几个深度学习任务时，这么点消费者完全没有办法应付之后的任务了，导致简单的几十k数据落盘任务都需要积攒天级以上的时间才能完成。

所以，深度学习任务单独开个queue分流不阻塞其他任务，就解决了此次问题。。（感觉好蠢，浪费了一个上午