Loading... # 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分流不阻塞其他任务,就解决了此次问题。。(感觉好蠢,浪费了一个上午 最后修改:2020 年 12 月 30 日 03 : 59 PM © 允许规范转载 赞赏 如果觉得我的文章对你有用,请随意赞赏 赞赏作者 支付宝微信