我应该什么时候在 Akka 中使用 Actors 与 Remote Actors？
我知道两者都可以扩大机器，但只有远程演员可以扩大，那么普通演员有什么实际的生产用途吗？
如果远程 Actor 仅具有较小的初始设置开销，并且与普通 Actor 相比没有任何其他主要开销，那么我认为使用远程 Actor 将是标准，因为它可以轻松扩展和扩展。即使永远不需要扩展生产代码，也可以选择（如果它不附带包袱）。
任何关于何时使用 Actor 与 Remote Actor 的见解将不胜感激。
问问题
1308 次
3 回答
8
远程 Actor 无法扩展，它们只是对另一台机器上本地 Actor 的远程引用。
对于 Akka 2.0，我们将引入集群 Actor，这将允许您编写 Akka 应用程序并仅使用 config 对其进行扩展。
于 2011-09-06T18:07:10.373 回答
2
常规 Actor 可用于在本地项目中发送消息。至于远程参与者，您可以使用它来向相关项目发送消息，这些项目连接到发送消息的项目。
请参阅此处了解远程 Akka Actors
于 2012-11-02T08:28:30.073 回答
1
问题是“如果远程参与者只有很小的初始设置开销并且没有任何其他主要开销，那么我认为使用远程参与者将是标准”。然而，分布式计算的谬误表明，假设使用任何技术进行远程处理没有开销是一个设计错误。您有将消息复制到字节并通过网络接口传输的开销。您还面临着不同进程的启动、关闭、停滞或无法访问以及网络出现故障导致丢失、重复或重新排序消息的所有复杂性。
这篇很棒的文章有现实世界中奇怪的网络错误的例子，这些错误使得远程处理很难做到防弹。Akka 项目负责人 Roland Kuln 在他关于 akka 的免费视频课程中说，根据他的经验，每发送 1T 网络消息，他就会发现一个损坏。年轻人的分布式系统注释说“分布式系统往往需要实际的而不是模拟的分发来清除它们的错误”，所以即使是好的单元测试也不会成为一个完美的系统。有很多建议说远程处理不是“免费的”，而是要努力做到完美。
如果您需要使用远程处理来提高可用性，或者大规模迁移，那么请注意，akka至少进行一次交付，并且可能存在重复。因此，您必须确保重复的消息不会产生不良结果。
当您开始使用远程处理时，您就有了一个分布式系统，这会带来挑战，在分布式系统中讨论这些挑战是为了乐趣和利润。除非您正在做非常简单的事情，例如对重复消息具有幂等性的无状态计算器，否则事情会变得很棘手。上面链接中那个akka视频课程的任务之一是制作一个复制的键值存储，它可以通过自己编写逻辑来处理丢失的消息。它远非一项简单的任务。分布在不同进程中的状态变得非常困难，参与者封装了状态，因此分布参与者可能变得非常困难，具体取决于您正在构建的系统的一致性和可用性要求。
这一切都意味着，如果您可以避免远程处理并实现您需要实现的目标，那么您将明智地避免它。如果您确实需要远程处理，那么 Akka 会因为其位置透明性而变得容易。因此，虽然它是一个很好的工具箱，可以随身携带；您应该仔细检查工作是否需要工具箱中的所有工具或只需要最简单的工具。
于 2014-10-19T11:35:08.337 回答