架构设计：系统存储（24）——数据一致性与Paxos算法（中）

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

学习必须往深处挖，挖的越深，基础越扎实！ 

 

2-1-1. Prapare准备阶段

首先需要介绍几个在Acceptor角色上需要被持久化保存的数据属性：

• PrepareVote保存了当前Acceptor接收到的已完成投票授权的最大投票轮次
• AcceptedVote保存了当前Acceptor在赋值阶段完成投票赋值的投票轮次
• AcceptedValue保存了当前Acceptor在赋值阶段被赋予的值

1、第一个阶段Proposer和Acceptor至少要完成一次网络通讯，其主要目的是确定针对提议X的当前投票轮次是否能被授权。换句话说，根据Acceptor在准备阶段的工作原则，即使确定当前投票轮次的编号值是大于Acceptor中记录的PrepareVote的值。处理过程很简单，即Proposer向 所有Acceptor 发出关于发起提议X的新一轮投票的申请，并等待各个Acceptor进行响应。当然会有一个超时时间，如果超过这个时间还没有得到Acceptor的响应，则认为已经被拒绝。 如果有超过N/2 + 1个节点在规定的时间内没有回复响应，那就说明整个选举系统发现了问题，则终止操作抛出错误，向客户端反馈异常信息 。

2、收到这个发起新的一轮投票操作的授权请求后，各个Acceptor开始判断是否可以进行授权。判断的原则只与PrepareVote有关，既是如果当前申请的投票轮次小于等于PrepareVote的赋值，则拒绝授权；其它情况都要接受授权，并更改PrepareVote属性为当前新的投票伦次编号。这里有一个隐藏含义，即这个Acceptor新授权的投票轮次编号，一定大于之前PrepareVote的值。

3、Proposer将负责汇总所有Acceptor的响应情况，并根据汇总的情况判断下一步的操作。无论Acceptor是授权这次投票还是拒绝这次投票，给出的响应信息中都最好包括当前Acceptor所记录的PrepareVote、AcceptedVote和AcceptedValue信息，这样有利于Proposer分析为什么会被Acce