赞
踩
最近在使用redis时发现总有一些消息队列中存在大量的处于unacked
状态的消息,一般来说,如果队列中ready
状态的消息数比较多,可以认为是消费者的处理能力不足,可以通过增加消费者来解决,而unacked
消息存在基本是有以下两点原因:
unacked
状态留在队列中。prefetch_count
设置的值取走相应数量的消息时,这些消息都会暂时处于unacked
状态。我司目前对redis的使用是基于Celery的,Celery对消息确认采用的是early ack
,即在消费者执行task之前,就已经向redis发送确认消息了,哪怕task产生异常也不会受到任何影响。所以队列中unacked
的消息不是自定义task异常产生的。若是消费者处理能力不足,则ready
状态的消息应该会有一定的堆积,但是也没有观察到这点,所以不能判定为消费者能力的限制。
有没有可能是消费者挂掉导致的呢?消费者挂掉后,unacked
的消息会变成ready
状态的消息重新放在队列中,待下次消费者启动后可以直接读取,所以也不会是这个原因。
通过以上分析,并没有发现消费者有何问题,只能尝试从生产者来分析了。Celery有两种生产消息的方式,delay
和apply_async
。
delay
直接向队列中投递消息,消费者立时可取,任务立即可执行apply_async
投递的定时消息,消费者立时可取,任务定时执行任务定时执行是Celery的功能,原理是amqp消息的header中存放了任务的执行时间,Celery会根据这个时间来执行任务,哪怕消费者挂掉了,当再次启动时,定时任务仍然能够正常执行。
但是,定时任务的ack消息并不是在消费者取走消息后就发送的,只有在任务真正执行前才会发送。这也是为什么clock_queue
中存在这么多unacked
消息的原因,不是真的出了什么问题,而是有这么多任务等待被执行呢。
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。