在我的一个项目中，鉴于其经过验证的性能记录，我决定将 Vertx 用于 HTTP API。然后，因为应用程序确实在内部使用事件队列，所以我开始想知道是否应该使用 Vertx event bus和 verticles，而不是使用我常用的 ArrayBlockingQueue 。我对 Vertx 还很陌生，所以我不知道它有多合适。我有使用 Akka 和 Actors 的经验，它们非常符合要求，但我不确定 Vertx 事件总线是否设计为扩展到每秒 100k 个事件？
最佳答案
我从 Vert.x 版本 3 开始就使用它，并用它完成了一些项目(这是我的主要堆栈，几年来)。我从未遇到过事件总线成为限制因素的情况。事件总线旨在处理如此大量的事件，甚至更多。正如 @injecteer 提到的，限制因素基本上是硬件，将处理多少事件取决于您如何处理它们以及如何扩展代码。
Vert.x 因此遵循非阻塞编程模型，您也应该遵循它......永远不要阻塞。 Vert.x 具有松散耦合的概念，这是通过使用“verticles”分割代码来解决的 https://vertx.io/docs/vertx-core/java/#_verticles 。您可以部署/启动这些 verticle 的多个实例(您的代码片段)。另一个基本概念是事件循环线程(默认核心数 * 2)。
每个部署的 Verticle 实例都将在特定的事件循环线程上运行，并且所有注册的处理程序(事件总线、http 服务器等)都会随时在此特定的事件循环线程上调用。这样，您就可以根据您的需要以“每线程”方式扩展代码。事件总线上的事件在 verticle 实例(以及 verticle 内的处理程序)之间以循环方式分发...顺便说一句，http 请求的处理程序也以循环方式分发。
集群模式有点不同。如何(反)序列化 dtos(Json、Protobuf 等)可能会在性能方面产生显着差异。集群事件总线在所有节点之间都有 TCP 套接字，这意味着事件是点对点发送的。另一方面，集群管理器(Hazelcast 是默认值)定义事件应发送到哪个节点(集群级别上的循环)，但事件不会通过集群管理器发送。例如。集群管理器知道哪个节点有消费者在事件总线上注册(在哪个地址)。
自 Vert.x 4 里程碑 5 起，集群管理器 SPI 提供了一个入口点，您可以在其中实现自己的循环替代方案，例如负载具体分布等
有一些基本概念，例如事件循环线程、非阻塞编程和 verticle(这不是强制性的，但推荐)。如果/当这些概念清晰时，您将获得几乎任何类型的应用程序的非常灵活的基础。我个人很喜欢它，也从未见过任何其他框架/技术能够达到接近可比的性能(具有适合负载的适当扩展)。
关于java - Vertx事件总线的性能与Java中的ConcurrentQueues一样好还是更好？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/63014319/