hazelcast - vert.x 事件总线在扩展方面是否有限制

Question

尝试了解 Vert.x 中 EventBus 的限制。

有 Vert.x 实例以集群模式运行，因此有多个 Verticle 运行在多台物理机上。假设我们有 2 台机器，每台机器有 10 个垂直体。

所以，从数字来看: 集群模式下的 1 个 Vert.x 实例 20 个 Verticle 实例(每台机器 10 个) 2台机器， 1 事件总线

每秒有 1000 000 个连接到达事件总线，并处理回 verticle。

如果2台机器不够我仍然可以得到100台机器，但是:

据我了解，事件总线 (EB) 是这里瓶颈吗？由于 EB 是一个“通信管道”，并且对于许多人来说它是一个，我想它将开始收集所有传入它的事件的所有噪音(地址 -> 服务) ，pub-sub等)，再加上它在节点之间运行，它会带来NET通信开销吗？如何扩展 EB？我应该关心它吗？ (或者 Hazelcast 集群应该处理这一切？)

我是否应该考虑在集群模式下使用 1 个 Vert.x 实例在 100 台机器上使用 10 个 verticle 创建 N 个集群？

问:问一个简单的问题，Event Bus 在扩展方面是否存在限制？我是否应该考虑使用 N 总线创建基础设施以确保我的系统是否正确缩放？

(尚未完成我的测试..)

Answer 1

当您使用集群EventBus时，会发生两件事:

1. Vert.x 在集群中注册的节点之间创建 TCP 连接
2. 集群管理器跟踪 EventBus 消息处理程序(将 EventBus 地址映射到节点标识符的多重映射)

然后，如果您发送一条消息(点对点)，Vert.x 将从集群管理器中获取一个处理程序，并使用 TCP 连接将其发送到远程节点。

或者，如果您发布一条消息(发布/订阅)，Vert.x 会将消息发送到至少有一个处理程序的所有节点(接收节点有责任传递消息)向所有本地处理程序发送消息)。

因此，集群式 EventBus 可扩展性有两个“限制”:多重映射的大小(随着地址和处理程序的数量而增长)和网络带宽。

当然，如果不进行测试就无法确定，但在现代硬件和良好的网络上，您应该能够使用固定数量的地址部署 100 个节点的集群。