distributed-system - Paxos 领导人选举可能不会终止

标签 distributed-system paxos

我正在研究 Paxos 所做的简单论文,我正在努力解决这样一个事实:如果 2 个提案者以更高的提案编号互相竞争,Paxos 不能保证进度,并且正如论文中所建议的,为了保证进度,一个杰出的必须选择提议者,使他成为领导者。

但是问题来了,人们建议使用 Paxos 来选举杰出的提议者,这又需要一个领导者来保证进展。

我知道给出的场景可能是特定于实现的,例如,如果给予要从中选择的进程的可区分集是有序的,我的意思是 P1 集 < P2 集。

但我想了解在实际实现中这是如何处理的?

最佳答案

通常的方法是简单地使用随机超时,因为领导者决斗的可能性较低。如果您在论文中搜索“超时”,那么它会提到这一点。

如果一个稳定的领导者平均需要 X 秒才能出现并取得进展(我们可以使用最小消息往返次数来估计),那么我们可以简单地让每个节点在某个时间间隔内随机超时,该时间间隔是一个倍数X。通过在每次尝试成为领导者时使用新的随机数,我们延长领导者决斗的可能性很低。

如果我们将 X 的较大倍数设置为随机超时的上限,则延长领导者决斗的概率就会降低。然而,在领导者出现之前,我们的平均时间也更长。所以这是一个权衡。

如果实现需要非常快速的故障转移,我们可以使用低超时随机间隔,但尝试实现一种能够快速解决领导者决斗的机制。你可以发明任何任意的机制。

确保一个节点有优势成为领导者的一种简单机制如下。每个节点都有一个唯一的编号,用于排序其选票。在领导者决斗期间,每个节点都可以使用指数退避,该退避按其自己的唯一数字进行缩放。例如,如果每次尝试成为领导者失败时节点编号为 N,我们可以将其超时窗口的上限乘以 1+1/N。这意味着在任何决斗期间,具有最高 N 的节点将更加积极地尝试成为领导者,因为其他节点将更快地后退。

关于distributed-system - Paxos 领导人选举可能不会终止,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/42252780/

相关文章:

algorithm - Paxos是如何处理丢包和新节点加入的?

linux - 奇数如何解决分布式系统中的脑裂?

time - Spanner 的只读事务

distributed - 为什么提议者发送的接受请求与从接受者获得的值相同?

algorithm - 如果修改 Paxos 算法,使接受器接受第一个值或最近的值,该方法是否会失败?

distributed-system - 分布式系统的好书

azure - Azure SQL 数据库是分布式 SQL 数据库吗?

amazon-web-services - 亚马逊 S3 架构

java - ZMQ 丢失事件在 jeromq scala 中传播

cassandra - 为什么cassandra中的领导人选举需要Paxos