我已经阅读了以下问题和答案：哪些设计决策会偏向 Scala 的 Actor 而不是 JMS？。
通常，我们使用已经存在多年的消息传递解决方案：使用JMS实现（如WebSphere MQ或Apache ActiveMQ）用于点对点通信，或者Tibco Rendevous用于多播消息传递。
它们非常稳定，久经考验，并提供高可用性和性能。尽管如此，配置和设置似乎比在Akka中复杂得多。
在上述产品（WebSphere MQ 或 ActiveMQ）到目前为止已成功使用的某些用例中，我应该何时以及为何应使用 Akka？为什么我应该考虑在将来的项目中使用 Akka 而不是 WebSphere MQ 或 Tibco RV？
我什么时候应该避免阿卡？它是否提供与其他解决方案相同的高可用性和性能？或者，将 Akka 与其他消息传递中间件进行比较是一个坏主意？
也许在JVM环境中还有另一种消息传递解决方案，除了JMS（点对点），TibcoRV（多播）和Akka之外，我还应该考虑？
首先，“较旧的”消息系统（MQ）在实现上较旧，但它们在工程理念上是较新的：事务持久队列。Scala Actors和Akka可能是一个较新的实现，但建立在旧的Actor并发模型之上。
然而，这两个模型在实践中最终非常相似，因为它们都是基于事件消息的：请参阅我对RabbitMQ vs Akka的回答。
如果您只打算为JVM编写代码，那么Akka可能是一个不错的选择。否则我会使用RabbitMQ。
此外，如果你是Scala的开发人员，那么Akka应该是一个不费吹灰之力的人。然而，Akka的Java绑定不是很像Java，并且由于Scala的类型系统而需要转换。
同样在Java中，人们通常不会制作不可变的对象，我建议你为消息传递这样做。因此，在Java中很容易意外地使用Akka做一些无法扩展的事情（对消息使用可变对象，依赖于奇怪的闭包回调状态）。使用 MQ，这不是问题，因为消息总是以速度为代价进行序列化。对于阿卡，他们通常不是。
与大多数 MQ 相比，Akka 在大量消费者中的扩展能力也更好。这是因为对于大多数 MQ（JMS、AMQP）客户端，每个队列连接都需要一个线程...因此，大量的队列==许多永久运行的线程。不过，这主要是客户端问题。我认为ActiveMQ Apollo有一个非阻塞调度程序，据称可以解决AMQP的问题。RabbitMQ 客户端具有允许您组合多个使用者的通道，但仍然存在大量使用者可能导致死锁或连接死机的问题，因此通常会添加更多线程以避免此问题。
话虽如此，Akka的远程处理是相当新的，可能仍然没有提供传统消息队列提供的所有可靠的消息保证和QoS（但这每天都在变化）。它通常也是点对点的，但我认为支持服务器到点，这通常是大多数MQ系统所做的（即单点故障），但有些MQ系统是点对点的（RabbitMQ是服务器到点）。
最后，RabbitMQ和Akka实际上是一对好搭档。您可以使用 Akka 作为 RabbitMQ 的包装器，特别是因为 RabbitMQ 不能帮助您处理消息的使用和在本地路由消息（在单个 JVM 中）。
何时选择阿卡
示例系统：交互式实时聊天系统
何时选择 MQ
示例系统：计划的事务批处理系统
根据相关评论进行编辑
我假设OP关注的是Akka和Message Queues都可以处理的分布式处理。我以为他说的是分布式Akka。使用 Akka 进行本地并发是与大多数消息队列相比的苹果到橙色。我说最多是因为您可以将消息队列模型作为并发模型（即主题，队列，交换）在本地应用，而 Reactor 库和 simple-react 都这样做。
选择正确的并发模型/库对于低延迟应用程序非常重要。像消息队列这样的分布式处理解决方案通常并不理想，因为路由几乎总是通过网络完成的，这显然比在应用程序内慢，因此Akka将是一个更好的选择。但是，我相信一些专有的MQ技术允许本地路由。另外，正如我之前提到的，大多数MQ客户端对线程非常愚蠢，并且不依赖于非阻塞IO，并且每个连接/队列/通道都有一个线程...具有讽刺意味的是，非阻塞io并不总是低延迟，但通常更节省资源。
正如你所看到的，分布式编程和并发编程的主题相当大，每天都在变化，所以我的初衷不是混淆，而是专注于分布式消息处理的一个特定领域，这是我在OP所关心的。在并发性方面，人们可能希望将搜索重点放在“反应式”编程（RFP /流）上，这是一种“较新”但与actor模型和消息队列模型相似但相似的模型，所有这些模型通常都可以组合在一起，因为它们是基于事件的。
我不是消息传递系统方面的专家，但您可以在应用程序中将它们与Akka结合使用，从而获得两全其美的优势。下面是一个示例，您可能会发现它对于试验 Akka 和消息传递系统非常有用，在本例中为 ZeroMQ：
