我有一个主题,其中多个订阅客户端使用默认预取运行。如果其中一个客户端速度很慢,则会降低其他订阅客户端的速度。我想为慢速消费者动态降低预取限制,但由于客户端随机减慢,这需要动态完成。
我想对以下解决方案进行原型设计: 为每个订户创建队列。线程池将从主题中删除事件并将事件复制到我的队列中。现在因为我为每个订户排队,所以每个客户端彼此独立。我将为每个队列设置预取限制。一旦达到该限制,我将放弃事件。缺点:现在每个队列都需要内存。
我想就上述解决方案或您认为可能适合我的案例的任何其他解决方案提出一些看法。
我在下面为我的用例添加了更多详细信息:
listener1处理速度:142 rps -
listener2处理速度:10 rps
事件产生速度 - 100 rps
默认预取限制:32000
情况1:当两个侦听器的预取限制相等时。 在约761秒内 - 主题在开始丢弃事件之前就已满。
案例2:当慢速消费者的预取限制小于快速消费者的预取限制时 listener2预取限制:64K 以上解决方案效果很好
有时监听器2的处理速度不会增加,监听器1的处理速度会降低(请注意处理速度不会完全反转,但我使用极值)并且case2不起作用。 现在listener1:10 rps listener2:142 rps 在开始删除事件之前,主题需要1523秒才能完成。一旦开始丢弃事件,侦听器1也将以与侦听器2相同的速度开始处理。
我正在寻找让每个听众独立运行而不是阻止他人的建议?
答案 0 :(得分:1)
您是否看过ActiveMQ页面上的documentation以处理缓慢的消费者。基本上,策略是使用挂起的消息限制策略让代理开始为那些移动缓慢并导致备份的消费者丢弃旧消息。由于缓慢的消费者导致Broker上的消息构建,因此您开始达到配置限制,这会导致Broker减慢生产者的速度。通过制定待处理的邮件限制,可以防止构建速度降低的速度。
您还可以关闭生产者流量控制,以允许生产者继续保持正常速率,并让消息假脱机到磁盘,直到磁盘达到其限制,这也包含在documentation中。