实用拜占庭容错和Raft 算法总结

实用拜占庭容错(Practical Byzantine Fault Tolerance, PBFT)

PBFT算法系统模型由一组节点构成的状态机复制模型。系统运行时存在一个主节点和副本节点。其中，视图为主节点在当前系统中的标识，若主节点出故障，系统会自动进行主节点的更变，即视图的更新，主节点的生成不需要选举；主节点生成如下：主节点 ，其中， 为主节点编号， 为视图编号， 为节点个数。
算法的流程图如图1所示：

图1：PBFT算法流程

如图1所示：节点0为主节点，节点3为拜占庭节点，整个流程主要分为请求（request）、预准备（pre-prepare）、准备（prepare）、提交（commit）和响应（reply）五个过程，其中主节点广播过程主要包括预准备、准备和提交三个阶段。预准备与准备阶段确保提交的请求在整个视图中被完全排序，准备和提交阶段则保证了在不同视图之间的确认请求的顺序。我们假设系统中的节点数为 3f+1个,各阶段详细步骤如下:
1、请求阶段：客户端发送请求消息 到主节点0，其中 为客户端请求消息标识， 为客户端操作， 为时间戳， 为客户端， 代表客户端对请求消息的签名；
2、预准备阶段：主节点0接受到客户端请求，主节点广播z预准备消息 到其他所有副本节点，其中， 为预准备消息标识， 为视图编号， 为请求消息序号， 客户端请求消息摘要， 代表主节点对预准备消息的签名， 是客户端的请求消息, 。副本节点接收到主节点广播预准备消息，若满足以下条件副本节点会进入准备阶段：
a) 客户端请求消息和预准备消息的签名正确，且 为 的摘要；
b) 当前视图编号为 ；
c) 副本节点未在视图 中接收过序号为 且摘要不同的客户端请求消息 ；
d) 预准备消息序号 在水线(watermark)上限 和下限 之间；水线用来防止失效节点通过数值较大的序号来导致序号空间的消耗；
如果未满足上述条件则作为非法请求而丢弃；
3、准备阶段：副本节点广播准备消息 ，其中 为准备消息标识， 为节点编号，其余参数与预准备消息中含义相同；并将预准备消息和准备消息写入本地消息日志；副本节点接收到其他副本节点广播的 消息后，若满足以下条件副本节点会进入提交阶段：
a) 准备消息的签名正确；
b) 当前视图编号为 ；
c) 准备消息的序号 在水线(watermark)上限 和下限 之间；
d) 摘要 和本地保存的 消息里的d一致；
若副本节点 收到 个满足条件的 消息后，则称节点当前状态为 ，且为 ，如果节点当前 状态为 ，则进入提交阶段；
4、提交阶段：副本节点广播确认消息 到所有副本节点，其中， 为确认消息标识，其余参数与准备消息相同，副本节点若满足以下条件将接受确认消息并写入本地消息日志：
a) 确认消息签名正确；
b) 当前视图编号为 ；
c) 准备消息的序号 必须在水线(watermark)上限 和下限 之间；
d) 摘要 和本地保存的 消息里的d一致；
若副本节点 收到 来自不同节点(包含自己)合法 消息，则称节点的状态为 且为 ，则副本节点执行 消息包含的操作，将 回复消息返回给客户端，其中 为回复消息标识， 为当前视图， 为客户端请求消息的时间戳， 为当前副本节点编号， 为执行客户端请求操作；
如果客户端在有效时间内没收到 个有效结果，则广播 到所有的副本节点。若该 已经被副本节点处理过，副本节点重新发送 到客户端；若该 没有被副本节点处理，副本节点会将改 重定向到主节点；若主节点没有再次将该 广播，则被怀疑是异常节点，触犯视图切换。
5、 响应阶段：主节点和其余副节点收到 消息后，同样的进行准备阶段中的校验过程。若节点收到了 2f+1个合法的 消息，则向客户端发送 消息。如果此时客户端如果收到 f+1个相同的 消息，则客户端的请求整个系统中达成了共识。
根据上述流程，在副节点故障或者恶意的情况下，其消息会当成非法请求丢弃；但对于主节点故障或者恶意，可能会给各个副节点发送不同的信息，或者让相邻的序号不连续，或者不去分配序号；各个副节点能检查序号合法性。若主节点故障或者故意不进行客户端请求的广播的问题，则客户端会戳发超时请求向所有副本节点广播请求消息，此时副本节点确认主节点是否故障或者恶意，将发起视图切换（View Change），系统会进行主节点更变，选择出新的主节点和新的视图编号。
补充： 水线含义
在分布式系统中，当副本执行完请求时，需要把之前记录的请求信息清除，但要确保正确的清除；故在PBFT中提出了 概念，即每隔 条去征求各副本节点的意见，若网络获得 节点的认同，就形成 ，故删除 之前的请求消息；
但当副本节点 向全网发出 共识后，其他副本节点可能并没有那么快也执行完 条请求，则副本节点不会立即得到响应，需继续执行 条请求，即 在其他副本节点就不是 。步伐快的副本节点可能会越来越快，把其他副本节点拉的越来越远，故PBFT算法提出高低水位概念；对于副本来说，低水位 为该副本节点上一个 的编号，高水位 ，其中，L为常数，一般为 周期 的常数倍，若副本节点步伐很快，该副本节点处理的请求编号达到高水位H后也得停止当前的请求处理，直到该副本节点 发生变化，才能继续处理当前请求。
当遇到以下条件会触发视图切换流程
a) 在一定时间内无法完成预准备阶段到准备阶段到提交阶段；
b) 在一定时间内无法完成正在进行的视图切换；
c) 有效的 消息数量达到 ，即当前已经有 个非拜占庭节点发起新的视图切换；
d) 消息不合法；即当前视图切换节点的主节点为拜占庭节点；
视图切换流程如图2所示：

图2 ：PBFT视图切换流程

1. 视图切换消息阶段：各副本节点 广播视图切换消息 给所有的副本节点，其中 为视图切换标识， 表示当前视图号加1， 为该副本节点 最新的 编号， 为包含 2f+1 个 消息的集合，用于证明检查点的正确性； 为一个 组成的集合, 为表示客户端请求消息， 表示请求消息 达成 状态的集合； 为节点序号； 为节点 的签名；
2. 视图切换回复阶段：副本节点 收集 信息并发送 确认消息到主节点，主节点统计 消息，辨别副本节点 是否正确
3. 新视图阶段：当主节点收到了2f个有效的 消息，广播 消息；其中 为新视图标识， 为 消息集合； 为 消息的集合；
   新的一轮视图中，各个节点在上一轮视图中 状态基础上进行共识流程的。若视图转换之前的消息 被分配了序号 , 并且达到了 状态，那么在视图转换之后，该消息也必须被分配序号 ；这是上一轮节点 状态，存在某个节点已经达到 状态；即保证视图转换之后，其他节点的 是为一样的序号 ；

Raft算法
Raft 将一致性问题分解成了三个相对独立的子问题，分别是 选举、日志复制和安全性；

1. 选举：若当前的 宕机，新的 会被选举；
   2.日志复制： 必须从客户端接收日志条目，并将日志条目复制到集群中的其他节点，并且强制要求其他节点的日志和自己的保持一致；
   3.安全性：若任何服务器节点已经应用一条日志条目到该服务器的状态机中，则其他服务器节点不会在同一个日志索引位置应用一条不同的条目；
   在我的假设中，监督节点作为主集群的 节点，故不存在 选举；如何保证安全性是待考虑的问题？Raft日志复制流程如图3所示：
   

图3：Raft日志复制流程
其中追加日志消息的如图4所示：

图4：追加日志消息
追加日志消息格式如下， 其中， 为追加日志标识， 为当前任期号， 为主节点ID， 为正在备份的日志记录之前的日志记录的index值； 为正在备份的日志记录之前的日志记录的 ； 为日志条目； 为Leader已经提交的最后一次日志记录的index值；
回复日志消息如5所示：

图5：回复日志消息