PBFT（一）：过程

PBFT 算法的基本流程主要有以下四步：

1. 客户端（不是主节点）发送请求给主节点（PBFT算法只是在各个服务器节点上运行的）
2. 主节点广播请求给其它节点，节点执行 pbft 算法的三阶段共识流程。
3. 节点处理完三阶段流程后，返回消息给客户端。
4. 客户端收到来自 f+1 个节点的相同消息后，代表共识已经正确完成。（要注意各个阶段确认消息的数量）

下面介绍 pbft 算法的核心三阶段流程，如下图所示：

算法的核心三个阶段分别是

• pre-prepare 阶段（预准备阶段）
• prepare 阶段（准备阶段）
• commit 阶段（提交阶段）

图中的C代表客户端，0，1，2，3 代表节点的编号，打叉的3代表可能是故障节点或者是问题节点，这里表现的行为就是对其它节点的请求无响应。0 是主节点。整个过程大致是如下：

首先，客户端向主节点发起请求，主节点 0 收到客户端请求，会向其它节点（不包括主节点）发送 pre-prepare 消息，其它节点就收到了pre-prepare 消息，就开始了这个核心三阶段共识过程了。

Pre-prepare 阶段：节点收到 pre-prepare 消息后，会有两种选择

• 一种是接受
• 一种是不接受

什么时候才不接受主节点发来的 pre-prepare 消息呢？
一种典型的情况就是如果一个节点接受到了一条 pre-pre 消息，消息里的 v 和 n 在之前收到里的消息是曾经出现过的（各个节点都有要给消息缓存池，可以将收到过的消息存储起来^[1]），但是 d 和 m 却和之前的消息不一致，或者请求编号不在高低水位之间（高低水位的概念在下文会进行解释），这时候就会拒绝请求。拒绝的逻辑就是主节点不会发送两条具有相同的 v 和 n ，但 d 和 m 却不同的消息。

Prepare 阶段：节点同意请求后会向其它节点发送 prepare 消息。

这里要注意一点，同一时刻不是只有一个节点在进行这个过程，可能有 n 个节点也在进行这个过程。因此节点是有可能收到其它节点发送的 prepare 消息的。在一定时间范围内，如果收到超过 2f 个不同节点的 prepare 消息，就代表 prepare 阶段已经完成。

Commit 阶段：于是进入 commit 阶段。(是在这个阶段后才执行客户的请求）

向其它节点（包括主节点）广播 commit 消息，同理，这个过程可能是有 n 个节点也在进行的。因此可能会收到其它节点发过来的 commit 消息，当收到2f+1个 commit 消息后（包括自己），代表大多数节点已经进入 commit 阶段，这一阶段已经达成共识，于是节点就会执行请求，写入数据。

注解：
V：当前视图的编号。视图的编号是什么意思呢？比如当前主节点为 A，视图编号为 1，如果主节点换成 B，那么视图编号就为 2，这个概念和 raft 的 term 任期是很类似的。
N：当前请求的编号。主节点收到客户端的每个请求都以一个编号来标记。
M：消息的内容
d或D（m）：消息内容的摘要
i： 节点的编号

【1】PBFT算法会将每个节点收到的请求都缓存下来，知道所有的节点都完成这个请求的时候（PBFT算法有一个stable checkpoint变量来表示当前所有节点已完成的最大请求序号），会在缓存中将这个消息清除，并且会记录到日志当中

参考 https://zhuanlan.zhihu.com/p/35847127