达到限制时Vert.x事件总线的行为 [英] Behaviour of Vert.x Event-bus when reaching the limit

查看:82
本文介绍了达到限制时Vert.x事件总线的行为的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我对事件总线/Hazelcast的工作原理缺乏了解.

I'm missing one piece of understanding of how Event Bus / Hazelcast works.

想象一下一个案例,其中有一个消费者和一个生产者纵向通过集群EB进行通信.消耗部分正在执行CPU/内存/IO密集型计算.

Imagine a case with a consumer and a producer verticles communicating over the clustered EB. The consuming part is doing CPU / memory / IO-intensive calculations.

当由于负载而在某个时候消费者无法立即处理消息时,会发生什么?

When at some point due to the load the consumer is not able to handle the messages immediately, what is going to happen?

消息是否将在环形缓冲区内排队,并最终在以后进行处理(考虑到Netty的 SingleThreadEventLoop 限制为20亿个,具体取决于

Would the messages be queueed inside the ring-buffer and eventually be processed later (considering Netty's SingleThreadEventLoop limits of 2 billion as per Size of event bus in vert.x)? Will they be dropped in case of reaching the limit?

通常,一旦集群中没有任何组件崩溃,是否可以持久地考虑EB中的消息并保证传递?

In general, can the messages in EB be considered persistent and with delivery guarantee, as soon as no component in the cluster crashes?

推荐答案

如果使用者无法处理消息,则Vert.x会将消息累积在内存中的队列中.

If the consumers cannot cope with the messages, Vert.x will accumulate messages in a queue in memory.

当队列达到其限制时,消息将被丢弃.可以使用

When the queue reaches its limit, the messages will be dropped. The number of elements in the queue can be configured with MessageConsumer.html#setMaxBufferedMessages. It does not depend on message size.

如果您需要交付保证,请不要使用EventBus,而应使用ActiveMQ之类的消息传递系统(Vert.x具有此类消息传递系统的客户端).

If you need delivery guarantees, don't use the EventBus, use a messaging system like ActiveMQ (Vert.x has clients for such messaging systems).

通常,Vert.x 尽力不输消息,但EventBus根本不是功能齐全的消息系统.

In general, Vert.x does its best not to lose messages but the EventBus is simply not a full-featured messaging system.

这篇关于达到限制时Vert.x事件总线的行为的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆