Scala的Actor相比JMS有哪些设计上的优势决策？

Question

使用Scala Actors 和使用JMS有哪些区别？例如从性能和可伸缩性的角度来看，相较于JMS，Scala Actor模型提供了什么优势？在哪些情况下使用Actors比使用JMS更为合适，即Actors解决了哪些JMS无法覆盖的问题？

- Kristian

Answer 1

JMS和Scala Actors在理论上很相似，但不要认为它们在架构上一定解决了相同的问题。Actors旨在成为共享内存并发的轻量级替代品，其中竞争和死锁通常更难意外创建。JMS是一个复杂的API，旨在跨越直接消息传递、发布/订阅、事务、EJB集成等领域。

最接近Actor的JMS等价物将是由非持久性、非事务型、非发布/订阅队列支持的消息驱动Bean。我将其称为“简单JMS Bean”。

现在回答你的问题。

性能是一个难以谈论的问题，因为JMS是一个规范而不是一种实现。不过，使用简单JMS Bean时，我预计性能会大致类似，可能会稍微比Actor更快，耗费更少的内存。当您添加JMS的其他功能，如发布/订阅、事务等时，性能自然会进一步降低，但这时你正在比较苹果和橘子。

至于可扩展性，简单的JMS Bean应该与Actor的扩展方式基本相同。将事务加入到JMS混合中将自然会对可扩展性造成一定程度的影响，具体取决于事务的范围。

关于Actor能做到JMS所不能的更广泛问题。好吧，没有内置的发布/订阅或事务，似乎Actor从JMS中减去了功能-这在广义上是正确的。但是这里有一件事：Actors需要的代码非常少，我可以愉快地将它们用于非常细粒度的并发处理。在普通的Java代码中，我可能会说“我不想处理JMS及其依赖项或其所需的代码等，所以我将只生成一个线程、使用锁并共享数据结构。”而在Scala Actors中，我更可能会说“我将简单地创建一个Actor并继续进行下一步操作”。

在设计上还存在哲学上的区别。Actor具有简单的、内置的监管者层次概念。通常采用“让它崩溃”设计。如果一个Actor由于某些原因死亡，那么另一个Actor将负责决定如何处理它，比如重新启动该Actor、杀死一组Actor并重启所有Actor，或者杀死一组Actor并自己处理问题以便让其他Actor来解决问题。这种事情可以在JMS上追加实现，但它不是API的核心，必须以某种方式进行外部管理。

顺便说一下，如果想要使用更多覆盖JMS范畴的Scala Actor库，请查看Akka。Akka还为许多常见的Actor层次结构策略提供了声明式方法。

- James Iry

---

我认为我已经涵盖了那个问题。我更新了最后几段以澄清这一点，并且我还解释了一些关于Actor层次结构的内容。 - James Iry

Kristian，不完全是这样。Akka actors通常比Scala actors更轻量级。然而，它们的API和配置设置略微复杂一些。当延迟/吞吐量不是问题时（例如用于生成工作任务），我使用Scala actors，而当它们是问题时或者如果我需要监督时，我使用Akka actors。 - Alexander Temerev

值得一提的是，通常情况下，JMS实现需要外部代理，而Akka/Actors可以在没有外部代理的情况下运行。当然，如果您需要进程/主机之间的消息传递，您可以选择相应的方法。 - jasonk