目录
3.1 如何定义“确定一个不可变变量的取值”这样的系统问题?
4.1 方案1:单 Acceptor + 多 Proposer
1. Paxos的理解困境
- Paxos 算法究竟在解决什么问题?
- Paxos 算法能解决的问题和分布式存储系统有什么关系?Paxos 能解决分布式存储系统哪个点上的问题?
- Paxos 算法的核心思想是什么?
- 第一阶段在做什么?
- 第二阶段在做什么?
2. Paxos和分布式存储系统
首先我们把 Paxos 能解决的一致性问题定义为:如何确定一个不可变变量的取值。
- 取值可以是任意二进制数据
- 取值一旦确定,就不可以更改,并且可以被获取到(不可变性,可读性)
因为变量的取值不可以更改,所以我们认为此变量是一个不可变变量。
那么,确定一个不可变变量的取值,和分布式存储系统有什么关系呢?
分布式存储系统具有以下特点:
- 数据具有可变性——在分布式存储系统中,数据本身是可变的,用户可以进行任意的增删改查。
- 多副本——分布式系统为了保证数据的可靠存储,一般会采用多副本的方式进行存储。
- 多个副本都有更新操作序列【Op1,Op2,……,Opn】——如果对多个副本执行更新操作的序列不进行任何控制,网络延迟,超时,多种故障等都会导致在多个副本中的操作顺序是不一样的,很难保证各个副本的一致性。
所以为了保证一致性,我们希望多个副本的操作序列是相同的不变的,即每个副本第一步干什么,第二步干什么,第n步干什么都是一致的。
Paxos协议可以依次确定不可变变量 Opi 的取值(即第 i 个操作是什么)。
每确定完 Opi 之后,可以让各个数据副本执行 Opi,以此类推,不断更新下去。
Google 的 Chubby,Megastore 和 Spanner 都采用了 Paxos 来对数据副本的更新序列达成一致。
3. 确定一个不可变变量的取值
3.1 如何定义“确定一个不可变变量的取值”这样的系统问题?
我们可以将“确定一个不可变变量的取值”的问题定义为,设计一个系统,来存储名称为 var 的变量。
- 系统内部由多个 Acceptor 组成,负责存储和管理 var 变量。
- 外部由多个 Proposer 机器任意并发调用 API,向系统提交不同的var取值。
- var的取值可以是任意二进制数据。
- 系统对外的API库接口为:propose(var, V) => <ok, f> or <error>。f 为系统已经确定下来的取值。
系统需要保证 var 的取值满足一致性。
- 如果 var 的取值没有确定,则 var 的取值为null;
- 一旦 var 的取值被确定,则不可被更改。并且可以一直获取到这个值。
系统需要满足容错特性:
- 可以容忍任意 Proposer 机器出现故障;
- 可以容忍少数(半数以下) Acceptor 机器出现故障。
为了理解简单,暂不考虑以下问题:
- 网络分化
- Acceptor 故障会丢失 自己存储的 var 的信息
3.2 确定一个不可变变量的难点
- 如何管理多个 Proposer 的并发执行?
- 如何保证 var 变量的不可变性?
- 如何设计一个系统容忍任意 Proposer 机器故障?
- 如何设计一个系统容忍半数以下 Acceptor 机器故障?
4 确定一个不可变变量的方案
4.1 方案1:单 Acceptor + 多 Proposer
先考虑系统由单个Acceptor组成,通过类似互斥锁机制,来管理并发的 Proposer 运行。
- Proposer 首先向 Acceptor 申请 Acceptor 的互斥访问权,然后才能请求 Acceptor 接受自己的取值。
- Acceptor 给 Proposer 发放互斥访问权,谁申请到互斥访问权,就接收谁提交的取值。
通过互斥访问权机制,可以让 Proposer 按照获取互斥访问权的顺序依次访问 Acceptor。
一旦 Acceptor 接收了某个 Proposer 的取值,则认为 var 值被确定,其他 Proposer 不再更改。