如何强制ActiveMQ连接为新消费者随机选择代理?
我使用以下 url 来创建 ActiveMQConnactionFactory:
failover:(tcp://server1:port,tcp://server2:port,tcp://server2:port)
我想要做的是从该代理网络创建多个消息使用者。 以下不是真正的代码,但它有助于理解我是如何做到这一点的:
ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory("BROKER_URL");
connection = connectionFactory.createConnection();
connection.start();
for (int i=0; i<10; i++) {
session = connection.createSession(false, Session.CLIENT_ACKNOWLEDGE);
Destination queue = consumerSession.createQueue("QUEUE_NAME");
consumer = consumerSession.createConsumer(queue);
consumer.setMessageListener(new MessageListener());
}
问题是所有消费者都将连接到一个随机选择的经纪人。 但我希望它们在经纪人网络上保持平衡。
我相信通过与工厂建立多个连接是可以做到这一点的。
但最佳实践是什么? 这是我想要的好事吗? :)
I use the following url to create ActiveMQConnactionFactory:
failover:(tcp://server1:port,tcp://server2:port,tcp://server2:port)
What I want to do is to create multiple message consumers from this network of brokers.
The following is not a real code, but it helps to undestand how I do that:
ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory("BROKER_URL");
connection = connectionFactory.createConnection();
connection.start();
for (int i=0; i<10; i++) {
session = connection.createSession(false, Session.CLIENT_ACKNOWLEDGE);
Destination queue = consumerSession.createQueue("QUEUE_NAME");
consumer = consumerSession.createConsumer(queue);
consumer.setMessageListener(new MessageListener());
}
The problem is that all consumers will be connected to one randomly choosen broker.
But I want them to be balanced over the network of brokers.
I believe it is possible to do that by creating multiple connections with the factory.
But what are the best practices for that?
And is this a good thing which I want? :)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
实际上,消费者不会连接到随机选择的经纪人。
连接是连接到代理的部分。使用您提供的连接字符串,您将有一个连接映射到一个随机选择的代理。所有消费者都有自己的会话,但这些会话将使用与该 ONE 代理相同的 ONE 连接。
我所知道的唯一设置是,您可以通过在连接字符串上设置
?randomize=false
来禁用故障转移协议的随机行为。这意味着您的连接将首先尝试第一个,然后是第二个,然后是第三个,依此类推。但要达到您的要求。我会让每个消费者都有自己的连接。这与故障转移协议中的随机功能一起可以对消费者进行负载平衡;但不是真的,那里没有智能,只是“随机化”它所连接的经纪人。
这意味着,我将执行以下操作(根据您的代码)
这样,每个消费者都将拥有与故障转移连接字符串的“a”代理的连接
问题更改后更新:
如果您愿意要让 ActiveMQ 为每个消费者随机选择一个代理,上述解决方案是可行的方法。
最佳实践是让消费者和生产者尽可能靠近。为此,我建议降低网络消费者优先级,因此本地消费者和生产者将具有最高优先级。只有当本地消费者不空闲时,它才会通过网络进一步分发给其他消费者。
除此之外,如果消费者端的操作长时间运行以设置较低的预取值,这将是一个好主意,这样消息就可以在代理网络周围实现负载平衡,而不是一个消费者抢夺 1,000 条消息,而其他消费者则抢走 1,000 条消息。消费者闲着。
Actually, the consumer would not be connected to a randomly chosen broker.
A connection is the part that connects to a broker. With the connection string you have provided, you will have ONE connection mapped to ONE randomly chosen broker. All consumers have their own sessions but these would use the same ONE connection to that ONE broker.
The only setting I know of, is that you can disable the randomize behavior of the failover protocol by setting
?randomize=false
on the connection string. This would mean your connection will first try the first, then the second, then the third, etc.But to achieve your requirement. I would make each consumer to have it's own connection. This, together with the randomize feature in the fail-over protocol would kinda load-balance the consumers; but not for real, there is no intelligence in there and is just "randomizing" the broker it is connecting to.
This means, I would do the following (from your code)
This way, each consumer will have it's own connection to "a" broker of your fail-over connection string
UPDATED AFTER QUESTION CHANGE:
If you want to let ActiveMQ randomly choose a broker for each consumer, the above mentioned solution is the way to go.
The best practice would be to put your consumers and producers as close to each other as possible. For this, I would recommend lowering the network consumer priority, so the local consumer and producer would have highest priority. Only when the local consumer is not idle, it would distribute further over the network to other consumers.
In addition to that, it will be a good idea if the operation on consumer side is long running to set a lower prefetch value, so that the messages do get load balanced around the network of brokers instead of one consumer snatching up 1,000 messages while other consumers are idle.