分布式学习——分布式一致性算法——paxos

攻城狮不是猫

已于 2024-05-11 09:54:18 修改

阅读量229

点赞数 1

分类专栏：分布式系统文章标签：分布式 paxos

于 2018-01-08 13:20:04 首次发布

本文链接：https://blog.csdn.net/u012613251/article/details/79001790

版权

分布式系统专栏收录该内容

14 篇文章 2 订阅

订阅专栏

随着大型网站的各种高并发访问、海量数据处理等场景越来越多，如何实现网站的高可用、易伸缩、可扩展、安全等目标就显得越来越重要。为了解决这样一系列问题，大型网站的架构也在不断发展。提高大型网站的高可用架构，不得不提的就是分布式。在关于分布式事务、两阶段提交协议、三阶提交协议一文中主要用于解决分布式一致性问题的集中协议，那么这篇文章主要讲解业内公认的比较难的也是最行之有效的paxos算法。

我认为对paxos算法讲解的最清楚的就是维基百科了。但是要看懂维基百科中的介绍需要很强的数学思维（paxos毕竟是一个算法），而且有很多关于定理的推论、证明等过程。那么本篇文章主要站在程序的角度，通俗的，循序渐进的讲解到底什么是paxos算法。

背景

Google Chubby的作者Mike Burrows说过， there is only one consensus protocol, and that’s Paxos” – all other approaches are just broken versions of Paxos. 意即世上只有一种一致性算法，那就是Paxos，所有其他一致性算法都是Paxos算法的不完整版。

Paxos算法是莱斯利·兰伯特（Leslie Lamport，就是 LaTeX 中的”La”，此人现在在微软研究院）于1990年提出的一种基于消息传递的一致性算法。为描述 Paxos 算法，Lamport 讲述了这样一个故事：

在古希腊有一个岛屿叫做Paxos，这个岛屿通过议会的形式修订法律。执法者（legislators，后面称为牧师priest）在议会大厅（chamber）中表决通过法律，并通过服务员传递纸条的方式交流信息，每个执法者会将通过的法律记录在自己的账目（ledger）上。问题在于执法者和服务员都不可靠，他们随时会因为各种事情离开议会大厅、服务员也有可能重复传递消息（或者直接彻底离开），并随时可能有新的执法者（或者是刚暂时离开的）回到议会大厅进行法律表决，因此，议会协议要求保证上述情况下可以能够正确的修订法律并且不会产生冲突。

什么是paxos算法

Paxos 算法是分布式一致性算法用来解决一个分布式系统如何就某个值(决议)达成一致的问题。

人们在理解paxos算法是会遇到一些困境，那么接下来，我们带着以下几个问题来学习paxos算法：

1、paxos到底在解决什么问题？

2、paxos到底如何在分布式存储系统中应用？

3、paxos的核心思想是什么？

paxos解决了什么问题

在关于分布式一致性的探究中我们提到过，分布式的一致性问题其实主要是指分布式系统中的数据一致性问题。所以，为了保证分布式系统的一致性，就要保证分布式系统中的数据是一致的。

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

所以，paxos算法主要解决的问题就是如何保证分布式系统中各个节点都能执行一个相同的操作序列。

上图中，C1是一个客户端，N1、N2、N3是分布式部署的三个服务器，初始状态下N1、N2、N3三个服务器中某个数据的状态都是S0。当客户端要向服务器请求处理操作序列：op1op2op3时（op表示operation）（这里把客户端的写操作简化成向所有服务器发送相同的请操作序列，实际上可能通过Master/Slave模式处理）。如果想保证在处理完客户端的请求之后，N1、N2、N3三个服务器中的数据状态都能从S0变成S1并且一致的话（或者没有执行成功，还是S0状态），就要保证N1、N2、N3在接收并处理操作序列op1op2op3时，严格按照规定的顺序正确执行opi，要么全部执行成功，要不就全部都不执行。

所以，针对上面的场景，paxos解决的问题就是如何依次确定不可变操作opi的取值，也就是确定第i个操作什么，在确定了opi的内容之后，就可以让各个副本执行opi操作。

Paxos算法详解

Paxos是一个十分巧妙的一致性算法，但是他也十分难以理解，就连他的作者Lamport都被迫对他做过多种讲解。我认为对paxos算法讲解的最清楚的就是维基百科了。但是要看懂维基百科中的介绍需要很强的数学思维（paxos毕竟是一个算法），而且有很多关于定理的推论、证明等过程。那么本篇文章主要站在程序的角度，通俗的，循序渐进的讲解到底什么是paxos算法。

我们先把前面的场景简化，把我们现在要解决的问题简化为如何确定一个不可变变量的取值（每一个不可变变量可以标识一个操作序列中的某个操作，当确保每个操作都正确之后，就可以按照顺序执行这些操作来保证数据能够准确无误的从一个状态转变成另外一个状态了）。

接下来，请跟我一步一步的学习paxos算法。

要学习paxos算法，我们就要从他要解决的问题出发，假如没有paxos算法，当我们面对如何确定一个不可变变量的取值这样一个吻问题的时候，我们应该如何解决呢？

这里暂不介绍paxos中的角色的概念，读者可以自行从维基百科中了解。不了解的话也可以直接往下看，看着看着就了解了。

问题抽象

我们把确定一个不可变变量的取值问题定义成：

设计一个系统，来存储名称为var的变量。

var的取值可以是任意二进制数

系统内部由多个Accepter组成,负责管理和存储var变量。

系统对外提供api,用来设置var变量的值
propose(var,V) => <ok,f> or <error>

将var的值设置为V，系统会返回ok和系统中已经确定的取值f，或者返回error。

外部有多个Proposer机器任意请求系统，调用系统API(propose(var,V) => <ok,f> or <error>)来设置var变量的值。

如果系统成功的将var设置成了V，那么返回的f应该就是V的值。否则，系统返回的f就是其他的Proposer设置的值。

系统需要保证var的取值满足一致性

如果var没有被设置过，那么他的初始值为null

一旦var的值被设置成功，则不可被更改，并且可以一直都能获取到这个值

系统需要满足容错特性

可以容忍任意proposer出现故障
可以容忍少数acceptor故障（半数以下）

暂时忽略网络分化问题和acceptor故障导致var丢失的问题。

到这里，问题已经抽象完成了，读者可以再仔细看看上面的系统描述。如果这样设置一个系统，是不是就可以保证变量var的不可变性了呢？

这里还是再简单讲解一下，上面的系统确实可以保证变量var的不可变性。

因为var的初始值为null，当有proposer请求接口propose（var，v）设置var的值的时候，系统会将var设置为v，并返回f（f==v）。

var变量被初始化以后，再有proposer请求propose(var,v)设置var的值的时候，系统会直接返回系统中已有的var的值f，而放弃proposer提供的v。

系统难点

要设计以上系统存在以下难点：

1、管理多个proposer并发执行

2、容忍var变量的不可变性

3、容忍任意Proposer的故障

4、容忍半数以下的acceptor的故障

解决方案一

先考虑整个系统由单个acceptor组成。通过类似互斥锁的方式来管理并发的proposer的请求。

proposer向acceptor申请acceptor的互斥访问权，当取得互斥访问权之后才能调用api给var变量赋值。
accepter向proposer发放互斥访问权，谁取得了互斥访问权，acceptor就接收谁的请求。
这样通过互斥访问的机制，proposer就要按照获取互斥访问权的顺序来请求系统。
一旦acceptor接收到一个proposer请求，并成功给var变量赋值之后，就不再允许其他的proposer设置var变量的值。每当再有proposer来请求设置var变量的值的时候，acceptor就会将var里面现有的值返回给他。

基于互斥访问权的acceptor的实现

acceptor会保存变量var的值和一个互斥锁Lock。

提供接口prepare()

加互斥锁，给予var的互斥访问权，并返回当前var的取值

提供接口release()

用于释放互斥访问权

提供接口accept(var, v)

如果已经加锁，并且当前var没有值，则将var的值设置成v，并释放锁。

proposer采用两阶段来实现

Step1、通过调用prepare接口来获取互斥性访问权和当前var的取值

如果无法获取到互斥性访问权，则返回，并不能进入到下一个阶段，因为其他proposer获取到了互斥性访问权。

Step2、根据当前var的取值f选择执行

1、如果f的取值为null，说明没有被设置过值，则调用接口accept(var ,v)来将var的取值设置成v，并释放掉互斥性访问权。
2、如果f的取值不为null，说明var已经被其他proposer设置过值，则调用release接口释放掉互斥性访问权。

总结：方案一通过互斥访问的方式来保证所有的proposer能够串行的访问acceptor，这样其实并没有解决多个proposer并发执行的问题。只是想办法绕开了并发执行。虽然可以在一定程度上保证var变量的取值是确定的。但是一旦获取到互斥访问权的proposer在执行过程中出现故障，那么就会导致所有其他proposer无法再获取到互斥访问权，就会发生死锁。。所以，方案一不仅效率低、而且还会产生死锁问题，不能容忍任意Proposer出现故障。
在之前提到的四个系统难点中，方案一可以解决难点1和难点2，但是无法解决难点3和难点4。

解决方案二

通过引入抢占式访问权来取代互斥访问权。acceptor有权让任意proposer的访问权失效，然后将访问权发放给其他的proposer。

在方案二中，proposer向acceptor发出的每次请求都要带一个编号（epoch），且编号间要存在全序关系。一旦acceptor接收到proposer的请求中包含一个更大的epoch的时候，马上让旧的epoch失效，不再接受他们提交的取值。然后给新的epoch发放访问权，让他可以设置var变量的值。

为了保证var变量取值的不变性，不同epoch的proposer之前遵守后者认同前者的原则：