java - Vertx 事件总线的性能与 Java 中的 ConcurrentQueues 一样好还是更好？

Question

在我的一个项目中，我决定将 Vertx 用于 HTTP API，因为它具有经过验证的性能记录。然后，因为应用程序确实在内部使用了事件队列，我开始怀疑是否应该使用Vertx 事件总线和 Verticle，而不是使用我通常的ArrayBlockingQueue。我对 Vertx 还是很陌生，所以我不知道它有多合适。我有使用 Akka 和 Actors 的经验，它们非常符合要求，但我不确定 Vertx 事件总线是否设计为每秒可扩展到 100k 个事件？

标签： javavert.x

Answer 1

我从版本 3 开始使用 Vert.x 并用它完成了一些项目（这是我的主要堆栈，几年以来）。我从来没有遇到过事件总线是限制因素的情况。事件总线旨在处理如此多的事件，甚至更多。正如@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（这不是强制性的，但推荐使用）。如果/当这些概念很清楚时，您将获得一个非常灵活的基础，可以用于任何类型的应用程序。我个人很喜欢它，也从未见过任何其他框架/技术达到接近可比性能（具有适合负载的适当缩放）。