Paxos算法

最新推荐文章于 2024-09-11 15:02:27 发布

狼星

最新推荐文章于 2024-09-11 15:02:27 发布

阅读量500

点赞数 1

分类专栏： Paxos 文章标签： java

本文链接：https://blog.csdn.net/langzhouxing/article/details/104063935

版权

Paxos 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

Paxos算法

1 算法简介

Paxos算法是菜斯利·兰伯特1990年提出的一种基于消息传递的，具有高容错性的一致性算法。Google Chubby的作者Mike Burrows说过，世上只有一种一致性算法，那就是Paxos，所有其他的算法都是Paxos算法的不完整版。Paxos算法是一种公认的晦涩难懂的算法，并且工程实现上也具有很大难度。较有名的Paxos工程实现有Google Chubby、ZAB、微信的PhxPaxos等

Paxos算法主要解决的问题是：分布式系统中如何就某个决议达成一致。

2 Paxos与拜占廷将军问题

拜占庭将军问题是由 Paxos 算法作者莱斯利·兰伯特提出的点对点通信中的基本问题。该问题要说明的含义是，在不可靠信道上试图通过消息传递的方式达到一致性是不可能的。所以，Paxos 算法的前提是不存在拜占庭将军问题，即信道是安全的、可靠的，集群节点间传递的消息是不会被篡改的。
一般情况下，分布式系统中各个节点间采用两种通讯模型：共享内存（Shared Memory）、消息传递（Messages Passing）。而 Paxos 是基于消息传递通讯模型的。

3 算法描述

3.1 三种角色

Paxos算法中有三种角色，分别具有三种不同的行为。但很多时候一个进程可能同时充当多种角色。

Proposer：提案者
Acceptor：表决者
Learner：同步者

3.2 Paxos算法的一致性

Paxos算法的一致性主要体现在以下几点：

每个提案者在提出提案时都会首先获取到一个具有全局唯一性的、递增的提案编号N。即在整个集群中是唯一的编号N,然后将该编号赋予其要提出的提案。
每个表决者在accept某提案后，会将该提案的编号N记录在本地，这样每个表决者中保存的已经被accept的提案中存在的一个最大编号提案，其编号假设为maxN。每个表决者仅会accept编号大于自己本地maxN的提案。
在众多提案中最终只有一个提案被选定。
一旦一个提案被选定，则其他服务器会主动同步（Learn)该提案到本地。
没有提案被提出则不会有提案被选定。

3.3 算法过程描述

Paxos算法的执行过程划分为两个阶段：准备阶段prepare与接受阶段accept

prepare阶段

提案者（Proposer)准备提交一个编号为N的提议，于是其首先向所有表决者（Acceptor)发送Propare(N)请求，用于试探集群是否支持该编号的提议。
每个表决者（Acceptor)中保存着自己曾经accept过的提议中的最大编号maxN。当一个表决者接受到其他主机发送来的prepare(N)请求时，其会比较N与maxN的值。有以下几种情况
a. 若 N 小于 maxN，则说明该提议已过时，当前表决者采取不回应或回应 Error 的方式来拒绝该 prepare 请求；
b. 若 N 大于 maxN，则说明该提议是可以接受的，当前表决者会首先将该 N 记录下来，并将其曾经已经 accept 的编号最大的提案 Proposal(myid,maxN,value)反馈给提案者，以向提案者展示自己支持的提案意愿。其中第一个参数 myid 表示该提案的提案者标识 id，第二个参数表示其曾接受的提案的最大编号 maxN，第三个参数表示该提案的真正内容 value。当然，若当前表决者还未曾 accept 过任何提议，则会将Proposal(myid,null,null)反馈给提案者。
c. 在 prepare 阶段 N 不可能等于 maxN。这是由 N 的生成机制决定的。要获得 N 的值，其必定会在原来数值的基础上采用同步锁方式增一。

accept阶段

当提案者(Proposer)发出 prepare(N)后，若收到了超过半数的表决者(Accepter)的反馈，那么该提案者就会将其真正的提案 Proposal(myid,N,value)发送给所有的表决者。
当表决者(Acceptor)接收到提案者发送的 Proposal(myid,N,value)提案后，会再次拿出自己曾经 accept 过的提议中的最大编号 maxN，或曾经记录下的 prepare 的最大编号，让N与它们进行比较，若 N 大于等于这两个编号，则当前表决者 accept 该提案，并反馈给提案者。若 N 小于这两个编号，则表决者采取不回应或回应 Error 的方式来拒绝该提议。
若提案者没有接收到超过半数的表决者的 accept 反馈，则有两种可能的结果产生。一是放弃该提案，不再提出；二是重新进入 prepare 阶段，递增提案号，重新提出 prepare请求。
若提案者接收到的反馈数量超过了半数，则其会向外广播两类信息：
a. 向曾 accept 其提案的表决者发送“可执行数据同步信号”，即让它们执行其曾接收到的提案；
b. 向未曾向其发送 accept 反馈的表决者发送“提案 + 可执行数据同步信号”，即让它们接受到该提案后马上执行。

4 Pacos算法的活锁问题

前面所述的Paxos算法在实际工程应用过程中，根据不同的实际需求存在诸多不便之处，所以也就出现了很多对于基本 Paxos 算法的优化算法，以对 Paxos 算法进行改进，例如，Multi Paxos、Fast Paxos、EPaxos。
eg：Paxos 算法存在“活锁问题”，Fast Paxos 算法对 Paxos 算法进行了改进：只允许一个进程提交提案，即该进程具有对 N 的唯一操作权。该方式解决了“活锁”问题。