何时使用actor而不是WebSphere MQ或Tibco Rendezvous等消息传递解决方案?

Kai*_*ner 104 java scala jms actor akka

我已经阅读过什么设计决策有利于Scala的Actors而不是JMS的问题和答案.

通常,我们使用已经存在多年的消息传递解决方案:将诸如WebSphere MQ或Apache ActiveMQ的JMS实现用于点对点通信,或者使用Tibco Rendevous用于多播消息传递.

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

何时以及为什么我应该将Akka用于上述产品(WebSphere MQ或ActiveMQ)到目前为止已成功使用的一些用例?为什么我应该考虑在未来的项目中使用Akka而不是WebSphere MQ或Tibco RV?

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

也许在JVM环境中还有另一个消息传递解决方案除了JMS(点对点),TibcoRV(多播)和Akka之外我还应该考虑?

Ada*_*ent 87

首先,"较旧"的消息系统(MQ)在实现中较早,但它们是工程理念中较新的:事务持久性队列.Scala Actors和Akka可能是一个较新的实现,但是建立在Actors的旧并发模型之上.

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

如果你只想为JVM编码,那么Akka可能是一个不错的选择.否则我会使用RabbitMQ.

此外,如果您是Scala开发人员,那么Akka应该是一个明智的选择.然而,由于Scala的类型系统,Akka的Java绑定不是非常Java并且需要进行转换.

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

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

据说Akka的远程处理是相当新的,可能仍然没有提供传统消息队列提供的所有可靠消息保证和QoS(但这种情况每天都在变化).它也通常是点对点的,但我认为支持服务器到对等,这通常是大多数MQ系统所做的(即单点故障),但是有点对点的MQ系统(RabbitMQ是服务器 - 对等).

最后RabbitMQ和Akka实际上是一对.您可以使用Akka作为RabbitMQ的包装器,特别是因为RabbitMQ无法帮助您处理消息的消耗并在本地路由消息(在单个JVM中).

什么时候选择Akka

  • 有很多消费者(想想数百万).
  • 需要低延迟
  • 打开Actor并发模型

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

何时选择MQ

  • 需要与许多不同的系统集成(即非JVM)
  • 消息可靠性比延迟更重要
  • 想要更多工具和管理员UI
  • 因为以前的观点更适合长时间运行的任务
  • 想使用与Actors不同的并发模型

示例系统:预定的事务批处理系统

编辑基于有关评论

我假设OP涉及Akka和消息队列都可以处理的分布式处理.那是我以为他在谈论分发的Akka.使用Akka进行本地并发是与大多数消息队列的比较.我之所以大多说是因为你可以在本地将消息队列模型应用为Reactor库和simple-react所做的并发模型(即主题,队列,交换).

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

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

  • BTW @IgorS.与消息队列一起使用的典型并发模型称为SEDA(分阶段事件驱动架构).除了使用队列,主题和交换本身就是一个并发模型(恰好也是分布式模型......就像演员模型一样).当有人说"错误的问题"时我也很鄙视..除了不恰当的问题,什么时候可以提出错误的问题?它的讽刺和精英可以说出类似的话. (4认同)
  • 我认为对错误问题的回答是不对的.您无法比较消息队列和并发模型.它们的构建是为了完全解决不同的任务,并且只有"消息"一词. (3认同)
  • 是的,没有.Akka支持分布式消息传递,您可以非常轻松地从消息队列范例(Google Spring的Reactor)构建并发模型.现在唯一的区别是RabbitMQ有持久的消息..哦等等Akka现在也支持.他可能会在标题中说"Actor",但明确指出Akka与许多基于消息的系统(并发和分布式系统)有很大的重叠. (2认同)

Dea*_*ler 4

我不是消息传递系统方面的专家,但您可以在应用程序中将它们与 Akka 结合起来,从而两全其美。下面是一个示例,您可能会发现它对于试验 Akka 和消息传递系统很有用,在本例中为 ZeroMQ:

https://github.com/zcox/akka-zeromq-java

  • ZeroMQ 并不完全是一个消息系统。它是某种改进的套接字。成熟的消息传递系统比 ZeroMQ 复杂得多。您链接中的项目似乎只是 ZeroMQ 与 Akka 的薄包装。 (6认同)