我见过的大多数Akka Actor用例都是高性能的多核服务器或本地集群。
我很好奇它是否适用于更远程的高延迟和高度失败的集群结构,例如 p2p 网络。
我想到的应用程序将有关于集群节点的可信任性和/或资源丰富性的规则,为它们提供一些状态,就像 bittorrent 那样。它还需要能够尽可能地跨集群传播事务,但最终或部分一致性是可以接受的。可扩展性将比一致性更重要。
AKKA 是构建这样的东西的潜在解决方案吗?与其他方法相比,它是否有任何特定的优点或缺点。
我见过的大多数Akka Actor用例都是高性能的多核服务器或本地集群。
我很好奇它是否适用于更远程的高延迟和高度失败的集群结构,例如 p2p 网络。
我想到的应用程序将有关于集群节点的可信任性和/或资源丰富性的规则,为它们提供一些状态,就像 bittorrent 那样。它还需要能够尽可能地跨集群传播事务,但最终或部分一致性是可以接受的。可扩展性将比一致性更重要。
AKKA 是构建这样的东西的潜在解决方案吗?与其他方法相比,它是否有任何特定的优点或缺点。
在这种情况下使用 Akka 的主要问题是 Actor 系统没有适合这种去中心化分布式计算的可扩展的成员管理系统。
您需要一些可以处理您在场景中描述的节点流失的东西。特别是,您需要能够监控节点何时加入、离开以及因故障而被假定为死亡和断开连接的东西。我建议使用基于八卦的注册表查看 Ibis: http ://www.cs.vu.nl/ibis/。您仍然需要一个众所周知的引导节点来启动系统,但 Ibis 使用的加入、选择、离开模型将在与基于 Gossip 的注册表结合使用时提供您正在寻找的可扩展性。该系统在某种程度上类似于 Akka Actor,因为它基于向上或向下调用和传递消息的单向管道的系统。一旦你掌握了它,就很容易对分布式的东西进行编程。
就最终一致性而言,这是大型分布式环境中已知的难题。我需要更多地了解您想要分发的交易类型以及在那里提出更多建议所需的一致性和历史保存水平。最近的一些论文证明,尽管在如此恶劣的环境中,你能想出的最好的方法是分叉因果一致性,至少每个人都可以看到历史已经分叉,如果不能确定“获胜”分叉,没有其他分叉解决机制。
比特币是这个领域的一个有趣的例子,其中“获胜”由最长的链决定,但这个领域还有其他解决方案可能会或可能不会根据应用程序语义工作。您的问题有点太模糊,无法在如此大的设计空间中给出具体建议。