gpt4 book ai didi

jms - JMS 是否可能出现 "fair queuing"

转载 作者:行者123 更新时间:2023-12-03 00:04:03 24 4
gpt4 key购买 nike

我需要实现一个公平的排队系统,以便根据某个消息 header 的值,针对当前排队的消息上该 header 的所有值,以循环方式处理消息。

系统中的消息自然地按某些属性进行分组,其中有数千个可能的值,并且当前排队的消息的值集随着时间的推移而变化。打个比方,消息的标题是消息创建时时间的毫秒部分。因此, header 的值将在 0 到 999 之间,并且该值将在当前排队的所有消息中进行某种分布。

我需要能够按顺序使用消息,以便没有特定值优先于任何其他值。如果排队消息的 header 值是这样分布的

value | count
------|-------
A | 3
B | 3
C | 2

那么消费顺序就是A,B,C,A,B,C,A,B

如果将具有其他值的消息添加到队列中,它们应该自动添加到循环序列中。

这意味着对当前排队消息的一些了解,但不需要消费者持有这些知识;经纪人可能有以某种方式订购交付的机制。

存在某个阈值,超过该阈值就会开始公平排队,这是可以接受的。也就是说,如果阈值为 10,则可以顺序处理 10 条具有相同值的消息,但处理的第 11 条消息应该是依次处理的下一个值。 Next 可能是相同的值,如果唯一的排队消息具有该值。

可能值的数量可能不允许简单地为每个值创建一个队列并迭代队列,尽管这尚未经过测试。

我们正在使用 HornetQ,但如果有替代方案可以提供这些语义,那么我很想知道。

消息是作业, header 值是用户 ID。我们所寻求的是,在一定限度内,任何给定用户的作业都不会不适本地延迟任何其他用户的作业;用户生成 100 万个作业不会导致其他用户的后续作业等待这 100 万个作业得到处理。

HornetQ 中队列上的消费者按照创建顺序进行评估,因此向队列中添加选择性消费者不会阻止任何包罗万象的消费者接收与过滤器匹配的消息。

JMS 组似乎没有帮助,因为它将给定组(用户?)与给定消费者联系起来。

一个潜在的解决方案是根据需求在某个主题上创建选择性消费者(例如:来自同一用户的 10 条连续消息),并通过某种方式管理所有选择性消费者的生命周期,以确保包罗万象的消息不会处理相同的消息。虽然可能,这似乎确实有一些繁重的同步要求。

最佳答案

要考虑的第一个选择是拥有一个多线程消费应用程序。假设每个 session /消费者都有一个线程,则可以使用选择器设置同步或异步接收。每个选择器都与特定用户相关。

假设 JVM 在线程分派(dispatch)方面是合理公平的(我很乐意假设)并且应用程序代码中不存在任何死锁,我断言需求将得到满足。一个线程可能会被用户的一百万个作业卡住,其余的不会受到影响。

但是,如果需要单线程应用程序,那么 JMS 规范本身就无济于事。当然,他们可能是供应商扩展,这可能会有所帮助。然而,另一个选项是应用程序查看每条消息并将其放入用户 ID 的特定队列中。最终的消费应用程序本身将在这些队列之间“循环”以获取工作。需要另一个应用程序,但您有一个非常确定的系统。

关于jms - JMS 是否可能出现 "fair queuing",我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/26378245/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com