AKKA远程演员是否可以在p2p swarm环境中使用?

时间:2013-04-12 10:36:05

标签: java scala akka distributed-computing distributed-transactions

我见过Akka个演员的大多数用例都是高性能的多核服务器或本地集群。

我很好奇它适用于更远程的高延迟高度失败的群体结构,例如p2p网络。

我想到的应用程序将有关于群集节点的可信性和/或资源丰富性的规则,给予它们一些状态,就像bittorrent一样。它还需要能够尽可能地在整个群体中传播交易,但最终或部分一致性是可以接受的。可扩展性优先于一致性。

AKKA是一个潜在的解决方案用于构建这样的东西吗?与其他方法相比,它是否具有特定的优点或缺点

1 个答案:

答案 0 :(得分:3)

在此上下文中使用Akka的主要问题是,Actor系统没有适当的可成对的成员资格管理系统用于这种分散的分布式计算。

您需要能够处理您在场景中描述的节点流失的内容。特别是,您需要能够监视节点何时加入,离开以及由于故障而被假定为死机和断开连接的东西。我建议使用基于八卦的注册表来查看Ibis:http://www.cs.vu.nl/ibis/。您仍然需要一个众所周知的引导节点来启动系统,但是,当使用基于Gossip的注册表时,Ibis使用的Join,Elect,Leave模型将提供您正在寻找的可扩展性。该系统在某种程度上类似于Akka actor,因为它基于上行或下行调用系统以及传递消息的单向管道。一旦你得到它的Fu就很容易编写分布式的东西。

就最终一致性而言,这是在如此大的分布式环境中已知的难题。我需要了解更多关于您要分发的交易类型以及在那里提出更多建议所需的一致性和历史保存级别。最近的一些论文已经证明,尽管在这样一个充满敌意的环境中,你能想到的最好的是fork-causal-consistency,至少每个人都可以看到历史已经分叉,如果没有确定“获胜”的分叉,没有其他一些分叉解决机制。

比特币在这个领域是一个有趣的例子,其中“获胜”由最长的链决定,但在这个领域还有其他解决方案可能会或可能不会取决于应用程序语义。你的问题有点过于含糊,无法在如此庞大的设计空间中提出具体的建议。