Vert.x 中的队列和 Verticle 数量限制
Limit on the amount of queues and verticles in Vert.x
我们现在正在重构用 Vert.x 编写的消息传递应用程序。该应用程序处理来自用户的传入消息。最初，它的实现是为了让单个 Verticle 实例监听事件总线中的单个队列并处理所有传入消息。
我们正在考虑做的是对其进行重构，使其工作方式有点类似于 actor 模型：我们为每个活动用户部署一个 Verticle 实例，并使其监听特定于用户的队列。这样 Verticle 实例可以维护特定于用户的状态，并且消息处理的并行化变得更加容易。
然而，问题在于这会导致部署大量 Verticle（并行 30k - 50k）和事件总线中的大量队列。而且我们还需要手动维护 Verticle（取消部署未使用的 Verticle，并在收到新用户的消息时部署它们）。
问题是 - 这种 actor 风格的架构是否适合 vert.x，它能否同时处理大量已部署的 Verticle 和事件总线队列？
这里有一个主要的更正 - EventBus 是一个队列。所以，你不会有 "huge number of queues"。只有一个。您将在一个队列中拥有大量地址。
但是这个数字有这么大吗？那么，50K个元素的HashMap算庞大吗？可能不是，至少在密钥方面是这样。现在请注意，这仅适用于非集群模式下的 Vert.x。集群 Vert.x 是不同的（虽然仍然应该工作）。
现在拥有那些 Verticles 是另一回事了。每个 Verticle 都是一个单独的对象，如果你打算在其中存储一些数据，它会更大。但是，如果您买得起具有不错 RAM (16GB+) 的机器，它应该可以正常工作。
不过，在这个解决方案中，我关心的是您计划按需部署 Verticle，然后取消部署它们。它确实会导致延迟，因此您的用户在发送第一条消息时会体验到性能下降。
你所说的 "actor-style" 并不意味着你必须为每个用户增加一个新的 Verticle 实例。如果这样做，您将获得一个冗余度为 98% 的系统。
为每个用户注册一个事件总线地址并使用某种持久存储来跟踪它们绝对足够了。这样的存储可以是用于长期持久性的任何数据库，也可以是用于短期的集群范围 SharedMap，或两者的组合。
也许您甚至不需要每个用户分配地址的方案。当用户通过某种 EventBusBridge 不断连接到您的系统时，这样的方案很好。如果不是这种情况，您可以为所有用户注册一个事件总线地址，并根据负载处理消息。
我们现在正在重构用 Vert.x 编写的消息传递应用程序。该应用程序处理来自用户的传入消息。最初，它的实现是为了让单个 Verticle 实例监听事件总线中的单个队列并处理所有传入消息。
我们正在考虑做的是对其进行重构，使其工作方式有点类似于 actor 模型：我们为每个活动用户部署一个 Verticle 实例，并使其监听特定于用户的队列。这样 Verticle 实例可以维护特定于用户的状态，并且消息处理的并行化变得更加容易。
然而，问题在于这会导致部署大量 Verticle（并行 30k - 50k）和事件总线中的大量队列。而且我们还需要手动维护 Verticle（取消部署未使用的 Verticle，并在收到新用户的消息时部署它们）。
问题是 - 这种 actor 风格的架构是否适合 vert.x，它能否同时处理大量已部署的 Verticle 和事件总线队列？
这里有一个主要的更正 - EventBus 是一个队列。所以，你不会有 "huge number of queues"。只有一个。您将在一个队列中拥有大量地址。
但是这个数字有这么大吗？那么，50K个元素的HashMap算庞大吗？可能不是，至少在密钥方面是这样。现在请注意，这仅适用于非集群模式下的 Vert.x。集群 Vert.x 是不同的（虽然仍然应该工作）。
现在拥有那些 Verticles 是另一回事了。每个 Verticle 都是一个单独的对象，如果你打算在其中存储一些数据，它会更大。但是，如果您买得起具有不错 RAM (16GB+) 的机器，它应该可以正常工作。
不过，在这个解决方案中，我关心的是您计划按需部署 Verticle，然后取消部署它们。它确实会导致延迟，因此您的用户在发送第一条消息时会体验到性能下降。
你所说的 "actor-style" 并不意味着你必须为每个用户增加一个新的 Verticle 实例。如果这样做，您将获得一个冗余度为 98% 的系统。
为每个用户注册一个事件总线地址并使用某种持久存储来跟踪它们绝对足够了。这样的存储可以是用于长期持久性的任何数据库，也可以是用于短期的集群范围 SharedMap，或两者的组合。
也许您甚至不需要每个用户分配地址的方案。当用户通过某种 EventBusBridge 不断连接到您的系统时，这样的方案很好。如果不是这种情况，您可以为所有用户注册一个事件总线地址，并根据负载处理消息。