9.算法进阶之分布式篇——Raft分布式系统达成共识

先搞清楚分布式一致性到底解决的是什么问题
我们知道数据库中 redo log经常用以记录数据变更，数据在被日志记录之后才会被应用。
如果多个节点存储的是同样的东西，我们怎么保证在经过一番更改之后，这些内容还是一致的呢？

日志一致性问题

客户端通常只会向分布式系统中的某个服务器发起请求，然后由这个服务器的一致性模块，在多个复制状态机之间进行消息的同步，正常情况下，多个节点同步都会成功，这样不同节点的日志自然也都是一致的，所有的节点都会以相同的顺序包含相同的请求，从外界看起来，行为也就像是一台机器一样。

但是如果服务器发生了故障，如何保持消息被正确的复制？
在实际系统中，一致性算法通常会存在哪些问题：

1. 在不同分区，网络延迟，乱序等情况，都要保证，只要返回数据，一定是正确的。
2. 可用性问题，小部分节点故障，不能影响大局，要用剩下大部分可用节点保证整个系统可用。
3. 不能依赖时钟来保持一致性，因为物理时钟在分布式系统中不可信。
4. 慢节点，即对于一个差生，不要求他考多好，但是不能影响整体的性能。

Raft

raft之前，paxos算法一直占据统治地位。
拜占庭条件源自一篇论文，也是 Paxos 的作者写的，他用一组将军围困一座城市的假想问题，描述当点对点通信的节点中出现了恶意节点传播不正确消息时，达成共识的困难处境。非拜占庭条件指的就是所有节点都是正常工作，只可能出现消息不可达，不会有消息错误的情况。

一致性问题，被 Raft 明确拆解成了三个比较独立的、更好理解的子问题，并且团队在许多实现细节上做了很多努力和权衡，也增强了系统里的许多限制，简化了需要考虑的状态，尽量让过程和接口的设计变得清晰易懂。
比如，Raft 中就引入了 Leader，由 Leader 进行全局消息的把控，也不允许日志中存在空洞的情况，都是一些比较常见的权衡。接下来我们就来逐一学习 Raft 拆解出来用于达成分布式共识的三个子问题：领导人选举、日志复制、安全性。

子问题1：领导人选举

Raft 引入 Leader 的概念，也就是领导人节点的思路，和两阶段提交里的协调者性质其实差不多的。