2022-7-27,测试人员反馈:运单揽收无法生成运单,查看了一下是因为队列阻塞了,原因是:自己在Rabbit客户端发送消息,没有考虑到消费端接受消息的condition,导致消息一直处于Unack状态,队列阻塞了。
问题点如下:
consumer.concurrency:消费端监听个数,开启消费的线程个数
consumer.prefetch:线程预处理个数(针对设置手动ack的)
当前配置的个数为:concurrency和prefetch均为2,所以出现4条unack消息时,队列阻塞了
解决方案:
因为是在测试环境,当时采取的是删除队列,重启服务,当处于生成环境时,应该可以采取新命名一个队列,将消息move到新的队列来消费
番外:
每个customer会在MQ预取一些消息放入内存的LinkedBlockingQueue中进行消费,这个值越高,消息传递的越快,但非顺序处理消息的风险更高。如果ack模式为none,则忽略。如有必要,将增加此值以匹配txSize或messagePerAck。从2.0开始默认为250;设置为1将还原为以前的行为。
prefetch默认值以前是1,这可能会导致高效使用者的利用率不足。从spring-amqp 2.0版开始,默认的prefetch值是250,这将使消费者在大多数常见场景中保持忙碌,从而提高吞吐量。
不过在有些情况下,尤其是处理速度比较慢的大消息,消息可能在内存中大量堆积,消耗大量内存;以及对于一些严格要求顺序的消息,prefetch的值应当设置为1。
对于低容量消息和多个消费者的情况(也包括单listener容器的concurrency配置)希望在多个使用者之间实现更均匀的消息分布,建议在手动ack下并设置prefetch=1。