这是我参与「第四届青训营 」笔记创作活动的第3天
1. 分布式系统
1.1 分布式系统面临的挑战
- 数据规模越来越大
- 服务可用性要求越来越高
- 快速迭代的业务要求系统足够易用
1.2 理想中的分布式系统
- 高性能：可扩展、低时延、高吞吐量
- 正确：一致性、易于理解
- 可靠：容错、高可用
2. 一致性与共识算法
2.1 多节点系统
在单个节点存在故障的可能性，一旦故障，系统将不可用，可以复制一个副本节点，防止系统不可用的情况发生。
2.2 Raft共识算法
多个副本节点之间需要共识算法来维持一致性，Raft就是一种经典的共识算法。
Raft算法中一个节点可以处于以下三种状态之一:
- Follower跟随者状态；
- Candidate候选者状态；
- Leader领导者状态。
Raft算法流程：
- Leader Election
所有的节点都以跟随者状态开始，如果跟随者没有收到领导者的消息，那么他们可以成为候选人；然后，候选人从其他节点请求投票，节点将以他们的投票进行回复；如果候选人从多数节点中获得选票，它将成为领导者，这个过程称为领导人选举Leader Election。
在Raft中，有两个超时设置可控制选举，一个是election timeout选举超时，另一个是heartbeat timeout心跳超时。
election timeout选举超时是指followers跟随者成为candidates候选者之前所等待的时间。election timeout被随机分配在150毫秒至300毫秒之间，选举超时后，跟随者成为候选者并开始新的election term选举任期，为自己投票并向其他节点发送Request Vote请求投票消息。如果接收节点在这个任期中还没有投票，那么它将投票给候选人并且节点将重置其election timeout选举超时，一旦候选人获得多数票，便成为领导者。
领导者开始向其追随者发送Append Entries追加条目消息，这些消息以heartbeat timeout心跳超时指定的时间间隔发送。跟随者然后响应每个Append Entries追加条目消息。此选举任期将持续到追随者停止接收心跳并成为候选人为止。
每个任期只能选出一位领导者，如果两个节点同时成为候选节点，则可能会发生分裂投票。如果发生分裂投票节点将等待新的选举，然后再试一次。
- Log Replication
系统的所有更改现在都要通过领导者，每次更改都将添加为节点日志中的条目。要提交条目，节点首先将其复制到跟随者节点，然后领导者等待，直到大多数节点都写了该条目，领导者通知跟随者该条目已提交。现在，集群已就系统状态达成共识，此过程称为Log Replication日志复制。
当选出一位领导者后，领导者需要将系统的所有更改复制到全部节点，通过使用与心跳相同的Append Entries添加条目消息来完成此操作。
该过程描述如下：
首先，客户端将更改操作发送给领导者，更改操作将添加到领导者的日志中，然后将更改操作在下一个心跳发送给追随者。一旦大多数追随者认可，便提交该条目。然后将响应发送给客户端。
面对网络分区，Raft也可以保持一致。
3. 其他常见共识算法
除了Raft外，还有许多共识算法，例如PBFT(实用拜占庭容错)算法。
PBFT算法流程
PBFT算法的共识过程
- 客户端(Client)发起消息请求request，并广播转发至每一个副本节点(Replica)；
- 由其中一个主节点(Leader)发起提案消息pre-prepare，并广播；
- 其他节点获取原始消息，在校验完成后发送prepare消息；
- 每个节点收到2f+1个prepare消息，即认为已经准备完毕，并发送commit消息；
- 当节点收到2f+1个commit消息时，我们就认为该消息已经被确认完成reply。
