java - 何时使用参与者而不是消息传递解决方案，例如 WebSphere MQ 或 Tibco Rendezvous？

Question

我已经阅读了 What design decisions would favour Scala's Actors instead of JMS? 的问题和答案.

通常，我们使用已经存在多年的消息传递解决方案:要么使用 JMS 实现(如 WebSphere MQ 或 Apache ActiveMQ)进行点对点通信，要么使用 Tibco Rendevous 进行多播消息传递。

它们非常稳定，经过验证并提供高可用性和性能。然而，配置和设置似乎比 Akka 复杂得多。

对于迄今为止已成功使用上述产品(WebSphere MQ 或 ActiveMQ)的某些用例，何时以及为何应使用 Akka？为什么我应该在 future 的项目中考虑使用 Akka 而不是 WebSphere MQ 或 Tibco RV？

我什么时候应该避免使用 Akka？它是否提供与其他解决方案相同的高可用性和性能？或者甚至将 Akka 与其他消息传递中间件进行比较是一个坏主意？

也许除了 JMS(点对点)、TibcoRV(多播)和 Akka 之外，我还应该考虑 JVM 环境中的另一种消息传递解决方案？

Answer 1

首先，“较旧的”消息系统 (MQ) 在实现上较旧，但它们在工程理念上较新:事务持久队列。 Scala Actors 和 Akka 可能是较新的实现，但构建在较旧的 Actors 并发模型之上。

然而，这两个模型在实践中非常相似，因为它们都是基于事件消息的:请参阅我对 RabbitMQ vs Akka 的回答。 .

如果您只想为 JVM 编写代码，那么 Akka 可能是一个不错的选择。否则我会使用RabbitMQ。

此外，如果您是 Scala 开发人员，那么 Akka 应该是显而易见的。然而，Akka 的 Java 绑定(bind)不是很像 Java 风格，并且由于 Scala 的类型系统需要进行转换。

同样在 Java 中，人们通常不会创建不可变对象(immutable对象)，我建议您为消息传递这样做。因此，在 Java 中很容易意外地使用 Akka 做一些不会扩展的事情(使用可变对象作为消息，依赖于奇怪的闭包回调状态)。使用 MQ 这不是问题，因为消息总是以速度为代价进行序列化。对于 Akka，它们通常不是。

与大多数 MQ 相比，Akka 在拥有大量消费者的情况下也能更好地扩展。这是因为对于大多数 MQ(JMS、AMQP)客户端来说，每个队列连接都需要一个线程……因此很多队列 == 很多永久运行的线程。不过，这主要是客户端问题。我认为 ActiveMQ Apollo 有一个非阻塞调度程序，据称可以为 AMQP 解决这个问题。 RabbitMQ 客户端具有允许您组合多个消费者的 channel ，但仍然存在大量消费者可能导致死锁或连接死亡的问题，因此通常会添加更多线程来避免此问题。

话虽如此 Akka's remoting是相当新的，可能仍然没有提供传统消息队列提供的所有可靠消息保证和 QoS(但每天都在变化)。它通常也是点对点的，但我认为它是否支持服务器对点，这通常是大多数 MQ 系统所做的(即单点故障)，但有些 MQ 系统是点对点的(RabbitMQ 是服务器-对等)。

最后 RabbitMQ 和 Akka 实际上是一对很好的搭档。 您可以使用 Akka 作为 RabbitMQ 的包装器，特别是因为 RabbitMQ 不能帮助您处理消息的消耗和本地路由消息(在单个 JVM 中)。

何时选择 Akka

拥有大量消费者(想想数百万)。

需要低延迟

开放Actor并发模型

示例系统:交互式实时聊天系统

何时选择 MQ

需要与许多不同的系统(即非 JVM)集成

消息可靠性比延迟更重要

想要更多工具和管理 UI

因为前面的观点更适合长时间运行的任务

想使用与 Actors 不同的并发模型

示例系统:调度事务批处理系统

根据相关评论进行编辑

我假设 OP 与分布式处理有关，这两个 Akka和消息队列可以处理。那是我假设他在谈论 distributed Akka . 与大多数消息队列相比，使用 Akka 进行本地并发是一个苹果与橙色的对比 .我说最多是因为你可以在本地应用消息队列模型作为并发模型(即主题、队列、交换)，这两个 Reactor图书馆和 simple-react做。

选择正确的并发模型/库对于低延迟应用程序非常重要。诸如消息队列之类的分布式处理解决方案通常并不理想，因为路由几乎总是通过线路完成，这显然比在应用程序中慢，因此 Akka 将是更好的选择。但是我相信一些专有的 MQ 技术允许本地路由。同样正如我之前提到的，大多数 MQ 客户端对线程非常愚蠢，并且不依赖非阻塞 IO 并且每个连接/队列/ channel 都有一个线程......具有讽刺意味的是，非阻塞 io 并不总是低延迟，但通常是更多资源高效。

正如您所看到的，分布式编程和并发编程的主题相当大并且每天都在变化，所以我的初衷不是混淆而是专注于分布式消息处理的一个特定领域，这正是我认为 OP 所关注的。在并发方面，人们可能希望将他们的搜索重点放在“响应式(Reactive)”编程(RFP/流)上，这是一种“较新”但类似于参与者模型和消息队列模型的模型，所有这些模型通常可以组合在一起，因为它们是基于事件的。