昨天发完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分流不阻塞其他任务,就解决了此次问题。。(感觉好蠢,浪费了一个上午