读paxos、raft算法后一些分享

分布式系统共识算法存在的意义

因为大部分分布式系统中容易发生服务器系统崩溃、网络波动等使服务器下线的情况，不同的服务器之间需要实现最终一致性，由此需要一个算法来使不同服务器之间高效的完成数据同步，在服务器事故多发的情况下同时保证高可用性。

共识算法的始祖-Paxos

paxos角色

首先将分布式系统分为三个角色，发起者，表决者，旁听者，最终目的是要将所有人对问题达成共识。
发起者会发起提案，表决者表示是否同意。
每个人可以同时充当多个角色。
只有主要发起者才能发起提案。

发起者两个不同阶段

在这个场景下，Paxos算法分为两个阶段。
阶段1-发起者学习提案。
1、发起者对超过半数的表决者发送准备提案【M1】
2、如果表决者没有接受过大于编号M1的提案，那么就接受该提案，并反馈已经接受过最大编号的提案【V】，并且承诺不在接受小于编号M1的提案。
阶段2-发起者发送接受请求
1、发起者对超过半数的表决者发送接受提案【M1,V】，该V是阶段1中表决者反馈的编号最大的提案中的V。
2、表决者收到【M1,V】，如果没有接受过编号大于M1的提案，那么接受提案。

旁听者学习方案

旁听者需要接受表决者选定的提案，有三种方案：
1、表决者接受一个提案就发送给所有的旁听者。缺点：需要大量通信，复杂度为M*N.
2、表决者向一个主要旁听者发送V，由主要旁听者发送给其他旁听者，缺点 主要旁听者下线会导致崩溃。
3、表决者向一个旁听者集合发送V，由集合发送给其他旁听者，缺点网络通信复杂度高。

这是基本的单法令协议，单法令协议只能对一个值保证最终一致性，除此之外如果加入多个值的讨论，极端情况下甚至会形成活锁，所以单法令协议基本只作理论研究，除此之外还存在多法令协议，此协议才是业务开发中多被使用到的算法。

Raft算法

核心概念摘要： 领导者、追随者、候选者、状态机、读写分离、预写日志、选举机制、两阶段请求。

与Paxos算法相同，Raft也具有三大角色：领导者、追随者、候选者。

领导者

作为从集合中被选举出来的角色，负责写请求，并将数据同步到追随者，定时会发送心跳保证与追随者之间的联系。

追随者

定时接受领导者的心跳，如果一定时间内没有接收到心跳请求则会转变成候选者，负责读请求。

候选者

追随者会转变成候选者，如果候选选举成功会转变成领导者，原领导者则会转变成追随者。

读写分离

简单概括Raft中的读写运作机制，在Raft中采取了读写分离的方式来减轻服务器并发量，且由领导者负责写入，追随者负责读请求。

预写日志数组

将所有写请求保存到一个数组中，由领导者同步到追随者，保证请求的顺序性。

状态机

每个节点实际存储数据的容器，由预写日志提交后写入到状态机中。

写请求

1、在追随者收到写请求之后会将领导者的节点ID反馈给客户端，由客户端再次向领导者发起请求。
2、领导者将写请求抽象成预写数组，然后追加到预写日志数组中。
3、领导者向所有追随者同步该预写日志。
4、追随者收到追随者请求，完成同步到预写日志中，返回一个同步完成的ACK。
5、领导者收到超过半数的追随者同步完成的信号，将预写日志提交，并向客户端回复 “写请求同步完成的”ack

读请求

服务器收到读请求的节点会向状态机中读取数据，由于两阶段请求+预写日志+状态机 能保证数据的最终一致性，如果想要达成即时一致性还需要额外操作，例如 只领导者读等操作，这里就不展开说了。

选举机制

每个领导者都有一个term（朝代编号），term具有单调递增的特性，当追随者长期没有接受到领导者的心跳时，就会转变成候选者，向所有追随者发起选举请求，并且此时已经具有term，由上一个朝代+1，在追随者收到请求后，会根据一定规则选择是否接受。此时有一个点需要注意（追随者不会接受term比自己小，且预写日志数组中最后一条记录比自己小的选举请求，这表明领导者和自己的连接比选举者更稳定）。在接收到半数以上的同意选举的ack时，会由选举者转变成领导者。

如何保证每一个朝代的已提交的预写日志不丢失

每一个提交的预写日志必定要经过半数以上的追随者同意，选举者也需要半数以上的追随者同意，其中必然有重复的服务器。

Raft中还有许多细节这里也没有展开说完，只讲了大体本人理解的部分。