演员模型不是反模式吗，因为“一劳永逸”的风格迫使演员记住一种状态吗？

Question

在学习Scala时，我学到的第一件事就是每个函数都返回一些东西。没有像Java中那样的“无效”函数/方法。因此，许多Scala函数在数学上都是真正的函数，并且对象在很大程度上可以保持无状态。

现在，我了解到actor模型是Scala等功能语言中非常流行的模型。但是，参与者促进了编程的“一劳永逸”风格，并且呼叫者通常不希望被呼叫者直接回复消息（使用“询问” /“？”方法时除外）。因此，参与者需要记住某种状态。

我是否假设角色模型更像是可伸缩性和可维护性之间的权衡（由于其状态），有时甚至可以认为是反模式？

Answer 1

是的，您基本上是对的（当您说可扩展性与可维护性时，我不太确定您在想什么）。

由于 Akka，Actors 在 Scala 中很受欢迎（这大概是因为它从 Lightbend 获得的支持而受欢迎）。然而，事实并非如此，actor 在函数式编程世界中普遍普遍流行（尽管我想到的所有语言都有实现）。下面是我对另外两个 FP 语言社区的大大简化的印象（所以用必要的盐量），这两个社区使用 actor（远？）的频率低于 Scala。

• Haskell 社区倾向于使用STM /通道（通常在STM 上下文中）。Straight up MVars也经常出人意料地被使用。
• Clojure 社区有时会吹捧自己的 STM 内置版本，但它的旗舰并发模型确实是core.async，这又是它的核心通道。

顺便说一句 STM，频道和演员都可以相互叠加；将它们作为相互排斥的方法进行比较有点奇怪。在实践中，虽然很少看到它们全部同时使用。

Actor 确实涉及状态（在 Akka 裙子类型安全的情况下），因此非常具有表现力，并且几乎可以在并发方面做任何事情。通过这种方式，它们类似于副作用函数，后者比纯函数更具表现力。事实上，演员在某种程度上是面向对象的纯粹本质，具有所有优点和缺点。

因此有一个相当大的 一块斯卡拉社区要说的是，如果大多数的，当你面对并发问题的时候，你正在使用的演员，这可能是一个反模式。

• 如果可以，尽量避免使用Futures 或scalaz.concurrent.Tasks。作为较少表现力的回报，您可以获得更多的可组合性。
• 如果您的问题自然适用于单一的全局状态（例如，以您想要强制执行的全局不变量的形式），请考虑 STM。在 Scala 社区中，虽然存在STM 库，但我的印象是 STM 通常是通过使用actor来模拟的。
• 如果您的并发问题主要围绕流式处理多个数据源，请考虑使用 Scala 的流式传输 库之一。