Paxos算法

Paxos中的角色

提议者（proposer）：proposer负责提出投票提议（proposal）和给出提议的决议（value）
投票者（acceptor）（一般三个以上）：收到提议后进行投票，以少数服从多数的原则决定是否接受提议和是否批准该value
若干客户端（client）：提议的产生者，客户端会将提议交个任意一个提议者，并由其提交投票
若干学习者（learner）：没有投票权但关心提议，它们只能观察投票结果，并更新自己的认识，获得被批准的值
若干合作者（coordinator）和一个leader（领导者）：改进后的Paxos算法中存在角色

在实际的系统中，通常只有服务端和客户端的概念，客户端一般扮演client、proposer和learner，服务端扮演accepter、coordinator和leader，一个节点可能承担多个角色

算法解析

• 第一阶段发起提议
  proposer向至少半数以上的acceptor发送prepare请求。由于可能会有多个proposer都期望对自己的提议进行投票，为了确保一次只处理一个提议，proposer会将各自的提议进行编号，此处编号可以理解为递增数字或时间戳。proposer会将提议和编号发向个acceptor。
  acceptor决定是否接受这个提议，并向proposer发送promise回应。收到提议的acceptor可能会进行一下操作之一：
  ①如果acceptor发现该提议的编号比之前接受过的提议更旧，则不会进行任何回应。
  ②如果acceptor发现提议的编号是当前最新的（大于当前接受的最新的编号），则会接受该提议，同时记录这个编号，承诺拒绝接受任何编号更旧的提议和决议。此时acceptor向proposer发送promise回应。如果acceptor对该提议已经有过决议，则在回应信息中加入编号最新的一个决议，注意如果该acceptor有历史决议，则理论上该决议已经得到半数以上acceptor批准，如果该提议没有历史决议，则在回应信息中加入一个空值
  proposer在一个时限内收集acceptor的回应。
  ①当发现半数以上的acceptor进行回应（同意该提议的投票），算法进入第二阶段。
  ②如果回应的acceptor未超过半数——可能由于网络状态、节点故障或编号太旧，则proposer需要更新提议的编号值，并在此重复第一阶段。
• 第二阶段决议的批准
  proposer向至少半数以上的acceptor发送accept请求。由于在第一阶段acceptor会将历史决议或空值附加到回应信息中，因此，此时，proposer可能进行如下操作之一：
  ①如果有多个acceptor在回应信息中附带了历史决议，则找到编号最新的历史决议（理论上也应该是超出半数的），将其发送个所有的acceptor，同时发送的还有上一轮使用的编号。
  ②如果没有任何一个acceptor已有决议，则proposer将自己提出的决议发给所有的acceptor，同时发送上一轮使用的编号。
  acceptor向proposer发送回应。当acceptor在第二阶段收到proposer发送的期望决议后，会检查其编号是否符合最新原则。
  ①如果编号是最新的（大于等于之前接受过的最新编号）则批准该决议，持久化存储并进行确认。
  ②如果编号不是最新的（如在此过程中其他proposer刷新了最新编号）则拒绝提议并附带当前acceptor处的最新编号。
  当proposer收到半数以上的acceptor的accepted回应时，有以下几种情况：
  ①如果发现有更新的编号，则表示过程中其他proposer刷新了最新编号，于是更新自身编号，返回第一阶段，重新提议。
  ②如果不存在更新的编号，则认为该决议已经达成共识。
  ③如果回应数量不足半数，可能由于网络状态或节点故障的原因，则更新自身编号，返回到第一阶段重新提议。
  ④如果系统中存在learner，则learner会通过主动或被动的方式，从accepted处了解该提议的当前决议，并更新自身认知
• 存在的问题和解决方案
  在经典的Paxos过程中，当proposer发现提议无法收到足够多的promise回应或accepted回应，理论上都会增加提议的编号，使之新一些，并重新提交prepare请求。因此，当多个客户端同时期望进行提议时，他们可能会不断提升epoch编号以抢占提议权，这可能造成投票效率降低，甚至产生活锁。
  为了解决这个问题，在第二阶段中提交的coordinator（合作者）角色被引入。coordinator角色可能有多个，但其中有一个最权威的称谓leader（领导者）。客户端或proposer需要进行提议时，可以向任何一个coordinator提交提议，coordinator会将其提交给leader，由leader决定对哪个提议进行投票。此外，在第二阶段，需要批准的值也是有leader传递给accepted。这种机制避免了proposer自行增加编号引起的活锁问题。