java - 什么样的设计决策会支持 Scala 的 Actor 而不是 JMS？

Question

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

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

Answer 1

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

与参与者最接近的 JMS 是消息驱动的 bean，它由非持久性、非事务性、非发布/订阅队列支持。我称之为“简单的 JMS bean”。

现在，回答你的问题。

性能是一个很难谈论的事情，因为 JMS 是一种规范而不是一种实现。尽管如此，当使用简单的 JMS bean 时，我希望性能大致相似，并且可能在时间和内存方面对 Actor 有一点优势。当您向 JMS 添加功能(例如发布/订阅、事务等)时，性能自然会进一步下降，但您正在尝试将苹果与橙子进行比较。

至于可伸缩性，简单的 JMS bean 的伸缩方式应该与参与者的伸缩方式几乎完全相同。将事务添加到 JMS 组合中自然会在一定程度上损害可伸缩性，具体取决于事务的范围。

更广泛的问题是 Actor 可以做什么而 JMS 不能。好吧，如果没有内置的 pub sub 或 transactions，actor 似乎会从 JMS 中减去 - 总的来说这是真的。但事情是这样的:actor 需要的代码非常少，以至于我可以很高兴地将它们用于非常细粒度的并发。在普通的 Java 代码中，我可能会说“我不想搞砸 JMS 及其依赖项或它需要的代码等，所以我只会产生一个线程，使用一个锁，并共享一个数据结构。”对于 Scala Actor ，我更有可能说:“我会挑选一个 Actor 然后继续前进。”

在设计上也存在哲学差异。 Actor 有一个简单的、内置的主管层次结构概念。 Actors 通常用于“让它崩溃”的设计。如果一个 Actor 因某种原因死亡，那么另一个 Actor 负责决定如何处理它，例如重新启动该 Actor ，杀死一堆 Actor 并重新启动所有 Actor ，或者杀死一堆 Actor 和自己，以便其他 Actor 可以处理问题。这种东西可以附加到 JMS 上，但它不是 API 的核心，必须以某种方式在外部进行管理。

顺便说一下，对于更多进入 JMS 涵盖的领域的 Scala Actor 库，请参阅 Akka . Akka 还为许多常见的 Actor 层次结构策略带来了一种声明式方法。