我应该什么时候在 Akka 中使用 Actor 与远程 Actor？
我知道两者都可以扩大机器，但只有远程演员可以扩大，那么普通演员有什么实际的生产用途吗？
如果远程 Actor 仅具有较小的初始设置开销，并且与普通 Actor 相比没有任何其他主要开销，那么我认为使用远程 Actor 将是标准，因为它可以扩展和扩展轻松。即使永远不需要扩展生产代码，也可以选择（如果它不附带包袱）。
任何关于何时使用 Actor 与 Remote Actor 的见解将不胜感激。
【问题讨论】：
标签： akka
远程 Actor 无法扩展，它们只是对另一台机器上本地 Actor 的远程引用。
对于 Akka 2.0，我们将引入集群 Actor，这将允许您编写 Akka 应用程序并仅使用配置对其进行扩展。
【讨论】：
常规 Actor 可用于在本地项目中发送消息。 至于 Remote Actors，您可以使用它来向与发送消息的项目连接的依赖项目发送消息。
Remote Akka Actors 请参考这里
【讨论】：
问题是“如果远程 Actor 仅具有较小的初始设置开销并且没有任何其他主要开销，那么我认为使用远程 Actor 将是标准”。然而Fallacies of distributed computing 指出，假设使用任何技术进行远程处理没有开销是一个设计错误。您有将消息复制到字节并通过网络接口传输的开销。您还面临着不同进程的启动、关闭、停滞或无法访问以及网络出现故障导致丢失、重复或重新排序消息的所有复杂性。
This great article 有现实世界中奇怪的网络错误的例子，这些错误使得远程处理很难做到防弹。 Akka 项目负责人 Roland Kuln 在他的free video course about akka 中说，根据他的经验，每发送 1T 网络消息，他就会发现一个损坏。 Notes on Distributed Systems for Young Bloods 说“分布式系统往往需要实际的，而不是模拟的分发来清除它们的错误”，所以即使是好的单元测试也不会成为一个完美的系统。有很多建议说远程处理不是“免费的”，而是要努力做到完美。
如果您需要使用远程处理来提高可用性，或者大规模迁移，请注意 akka 使用 at-least-once 交付可能会出现重复。因此，您必须确保重复的消息不会产生不良结果。
从您开始使用远程处理的那一刻起，您就有了一个分布式系统，这会带来挑战，这在Distributed systems for fun and profit 中进行了讨论。除非您正在做非常简单的事情，例如对重复消息具有幂等性的无状态计算器，否则事情会变得很棘手。上面链接中那个akka视频课程的任务之一是制作一个复制的键值存储，它可以通过自己编写逻辑来处理丢失的消息。它远非一项简单的任务。分布在不同进程中的状态变得非常困难，参与者封装了状态，因此分布参与者可能变得非常困难，具体取决于您正在构建的系统的一致性和可用性要求。
这一切都意味着，如果您可以避免远程处理并实现您需要实现的目标，那么您将明智地避免它。如果您确实需要远程处理，那么 Akka 会因为它的location transparency 而变得容易。因此，虽然它是一个很好的工具箱，可以随身携带；您应该仔细检查工作是否需要工具箱中的所有工具或只需要最简单的工具。
【讨论】：