哪些设计决策会支持Scala的Actors而不是JMS？

Question

使用Scala Actors而不是JMS有什么区别？

例如,从性能和可伸缩性的角度来看,与JMS相比,Scala Actor模型添加了什么？在哪些情况下使用Actors而不是JMS更有意义,即Actors解决JMS无法解决的问题是什么？

Answer 1

JMS和Scala演员具有理论上的相似性,但并不认为它们必然在架构上解决相同的问题.Actors意味着是共享内存并发的轻量级替代方法,其中种族和死锁通常更难以意外创建.JMS是一个复杂的API,旨在跨越直接消息传递,发布/订阅,事务,EJB集成等.

与actor相当的最接近的JMS是消息驱动的bean,由非持久的非事务性非pub/sub队列支持.我将其称为"简单的JMS bean".

现在,对你的问题.

性能是一件很难讨论的事情,因为JMS是一个规范而不是一个实现.在使用简单的JMS bean时,我希望性能大致相似,并且可能在时间和内存方面对actor有一点优势.当您向JMS添加功能(例如pub/sub,事务等)时,性能自然会进一步下降,但之后您会尝试将苹果与橙子进行比较.

至于可伸缩性,简单的JMS bean应该与actor完全一样地扩展.将事务添加到JMS组合中会自然地损害可伸缩性,具体取决于事务的范围.

关于JMS不能做什么的更广泛的问题.好吧,没有内置的pub子或事务,似乎演员从JMS中减去 - 而且广义上说这是真的.但事情就是这样:演员需要这么少的代码,我可以愉快地使用它们来实现非常精细的并发性.在普通的Java代码中,我可能会说"我不想搞砸JMS及其依赖项或它需要的代码等等,所以我只会生成一个线程,使用一个锁,并共享一个数据结构." 对于Scala演员,我更有可能说"我只是掀起演员并继续前进."

在设计上也存在哲学上的差异.演员有一个简单的,内置的管理层次结构概念.演员通常用于"让它崩溃"设计.如果一个演员因某种原因而去世,那么另一个演员负责决定该怎么做,比如重新启动那个演员,杀死一堆演员并重新启动所有演员,或杀死一堆演员本身以便其他一些演员可以处理问题.这种事情可以附加到JMS上,但它不是API的核心,必须以某种方式在外部进行管理.

顺便说一下,对于一个Scala actor库,它更多地移动到JMS所涵盖的领域,请参阅Akka.Akka还为许多常见的actor层次结构策略带来了声明性方法.