分布式一致性选举算法-Paxos

Paxos解决了什么问题

       分布式的一致性问题其实主要是指分布式系统中的数据一致性问题。所以，为了保证分布式系统的一致性，就要保证分布式系统中的数据是一致的。

      在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么他们最后能得到一个一致的状态。为保证每个节点执行相同的命令序列，需要在每一条指令上执行一个"一致性算法"以保证每个节点看到的指令一致。

      Paxos就是用于解决分布式系统中一致性问题的算法，在多个节中会存在节点间通信的问题，常用的两种节点通讯模型：共享内存（Shared memory）、消息传递（Messages passing），Paxos是基于消息传递的通讯模型的。 　　

Paxos的基本原理

paxos算法中的角色

    ·proposer 提案者，在实际应用中可以理解为request的接受者，该角色接收到用户请求，并向集群提出提案，要求执行该request。

    ·acceptor 决策者，决策者接收到来自其他的proposer的提案，并按照一定的逻辑决定是否接收当前的提案，也就是是否接收request并准备执行request的角色。

    ·learner 学习者，能够从其他节点获取某个被共识之后的提案。

paxos算法的处理阶段

准备阶段

Proposer 发送 Prepare

        Proposer 生成全局唯一且递增的提案 ID（Proposalid，以高位时间戳 + 低位机器 IP 可以保证唯一性和递增性），向 Paxos 集群的所有机器发送 PrepareRequest，这里无需携带提案内容，只携带 Proposalid 即可。

Acceptor 应答 Prepare
        Acceptor 收到 PrepareRequest 后，做出“两个承诺，一个应答”。

两个承诺：

·  第一，不再应答 Proposalid 小于等于（注意：这里是 <= ）当前请求的 PrepareRequest；

·  第二，不再应答 Proposalid 小于（注意：这里是 < ）当前请求的 AcceptRequest

一个应答：

·  返回自己已经 Accept 过的提案中 ProposalID 最大的那个提案的内容，如果没有则返回空值;

注意：这“两个承诺”中，蕴含两个要点：

1. 应答当前请求前，也要按照“两个承诺”检查是否会违背之前处理 PrepareRequest 时做出的承诺；

2. 应答前要在本地持久化当前 Propsalid。

决策阶段

Proposer 发送 Accept

        Proposer 收集到多数派应答的 PrepareResponse 后，从中选择proposalid最大的提案内容，作为要发起 Accept 的提案，如果这个提案为空值，则可以自己随意决定提案内容。然后携带上当前 Proposalid，向 Paxos 集群的所有机器发送 AccpetRequest。

Acceptor 应答 Accept

        Accpetor 收到 AccpetRequest 后，检查不违背自己之前作出的“两个承诺”情况下，持久化当前 Proposalid 和提案内容。最后 Proposer 收集到多数派应答的 AcceptResponse 后，形成决议

 

Paxos算法的处理流程

　　假如有Server1、Server2、Server3这样三台服务器，要从中选出leader。
　　整个选举的结构图如下：

准备阶段

1. 每个Server都向Proposer发消息称自己要成为leader，Server1往Proposer1发、Server2往Proposer2发、Server3往Proposer3发；

2.现在每个Proposer都接收到了Server发来的消息，但时间不一样，Proposer2先收到，然后是Proposer1，最后是Proposer3；

3. Proposer2首先接收到消息,所以他从系统中取得一个编号1，Proposer2向Acceptor2和Acceptor3发送为1的PID；

接着Proposer1也接收到了Server1发来的消息，取得一个编号2，Proposer1向Acceptor1和Acceptor2发送为2的PID;

最后Proposer3也接收到了Server3发来的消息，取得一个编号3，Proposer3向Acceptor2和Acceptor3发为3的PID；

4. 这时Proposer1发送的消息先到达Acceptor1和Acceptor2，这两个都没有接收过请求，所以接受了请求返回[2,null]给Proposer1，并承诺不接受编号小于2的请求；

5. 此时Proposer2发送的消息到达Acceptor2和Acceptor3，Acceprot3没有接收过请求返回[1,null]给Proposer2，并承诺不接受编号小于1的请求，但这时Acceptor2已经接受过Proposer1的请求并承诺不接受编号小于的2的请求了，所以Acceptor2拒绝Proposer2的请求；

6. 最后Proposer3发送的消息到达Acceptor2和Acceptor3，Acceptor2接受过提议，但此时编号为3大于Acceptor2的承诺2与Accetpor3的承诺1，所以接受提议返回[3,null]；

7. Proposer2没收到过半的回复，所以重新取得编号4，并发送给Acceptor2和Acceptor3，然后Acceptor2和Acceptor3都收到消息，此时编号4大于Acceptor2与Accetpor3的承诺3，所以接受提议返回[4,null]；

决议阶段

1. Proposer3收到过半（三个Server中两个）的返回，所以Proposer3提交了[3,server3]的议案；

2. Proposer1收到过半返回，所以Proposer1提交了[2,server1]的议案；

3. Proposer2收到过半返回,所以Proposer2提交了[4,server2]的议案；

4. Acceptor1、Acceptor2接收到Proposer1的提案[2,server1]请求，Acceptor2承诺编号大于4所以拒绝了通过，Acceptor1通过了请求, Proposer1的提案被通过一次；

5. Proposer2的提案[4,server2]发送到了Acceptor2、Acceptor3，提案编号为4所以Acceptor2、Acceptor3都通过了提案请求；

6. Acceptor2、Acceptor3接收到Proposer3的提案[3,server3]请求，Acceptor2、Acceptor3承诺编号大于4，所以拒绝了提案；

7. 此时过半的Acceptor都接受了Proposer2的提案[4,server2],Larner感知到了提案的通过，Larner学习提案，server2成为Leader；

一个Paxos过程只会产生一个议案所以至此这个流程结束，选举结果server2为Leader；

 

转载于:https://my.oschina.net/ittrueman/blog/1612492