分布式系统一致性问题与Raft算法（上）

最近在做MIT6.824的几个实验，真心觉得每一个做分布式相关开发的程序员都应该去刷一遍（裂墙推荐），肯定能够提高自己的技术认知水平，同时也非常感谢MIT能够把这么好的资源分享出来。

其中第二个实验，就是要基于raft算法，实现一个分布式一致性系统。但今天先不说raft算法，而是先讨论下什么是分布式一致性问题，以及为什么它会难！！下一章再说raft是如何设计从而解决了分布式共识这一难题。

什么是分布式一致性问题

首先，什么是分布式系统一致性问题？分布式系统这个词应该不用多解释，简单地说就是由多个节点（一个节点即一台物理机器或一个进程），异步得通过网络通讯而组成的系统。

而一致性（Consistency），这个词在不同的场景下有不同的含义，比方说大家比较熟的应该是在关系型数据库中事务的一致性。但在分布式系统中，一致性的基本含义是对进行进行一个或多个操作指令之后，系统内的其他成员对这些操作指令的结果能够达成共识，也就是对结果的看法是一致的。

举个例子，比方说有多个客户端，这些客户端出于某种原因，都要对分布式系统中的变量v赋值，客户端A发起一个赋值请求修改v=a，客户端B也发起一个请求修改v=b，等等等。但最终在某一个时刻布式系统内都能够对v的值产生一个共识，比如最终大家都知道v=a。而不会说系统内不同节点对这个值有不同的看法。

要做到这一点很难吗？是的，很难。

注：一致性这个词其实包含挺广的，但这里特质共识这个意思，所以有时候也会用共识的说法，知道是一个意思就行了。

为什么分布式一致性问题很难

明白了什么是分布式一致性问题之后，我们再来讨论为什么分布式一致性会很难。

如果是在单机环境下，实现一致性是很容易做到的，基本上我们开发的程序都能够做到。但在分布式环境下，则难度放大了无数倍。因为在分布式环境下节点间的状态是通过网络通信进行传输的，而网络通信是不可靠的，无序的，注意这里的不可靠不是说tcp或udp的那个可靠，而实无法通过网络通信准确判断其他节点的状态。

比如A向B发送了一个请求，B没有回应。这个时候你没办法判断B是忙于处理其他任务而无法向A回复，还是因为B就真的挂掉了。

顺便说一点，分布式一致的问题往往还具有一定的欺骗性。

它具有一定欺骗性的原因在于分布式一致性的问题直观感受上往往比较简单，比如上面的A向B发送请求的问题，我们无论选择直接认为B挂掉，或者选择让A不断进行重试，看上去似乎都能解决这个问题。但随着而来的又会有新问题，比如A选择认为B挂掉而进行失败处理，那么系统继续无碍运行。但如果B只是因为系统任务繁忙，过一会恢复作业，A就因为自身的选择破坏了数据的一致性，因为在B断线期间系统就不一致了。这就又出现了新的问题。

总结起来，就是看似简单的问题，引入简单的解，往往又会出现新的问题。而后又继续在此基础上“打补丁”，而后又会出现新的问题，不断循环往复，一个简单的问题不断叠加，就变成了超级复杂棘手的问题。就像筑堤堵水，水不断涨，堤坝不断堆砌，最终到了一个谁也没法解决的境地。

说回刚刚的话题，按照刚刚的例子，其实可以引出另一个问题，那就是活性（liveness）和安全性（satefy）的取舍。

活性（liveness）与安全性（satefy）

活性与安全性，这个要怎么理解呢？

刚刚说到，当A向B发送请求，B没有及时回应。但这个时候，A是无法准确知道B真正的状态的（忙于其他任务还是真的挂掉了），也就是说我们是无法做到完全正确的错误检测。

这种时候按照上面的说法，有两种选择，

1. 任务B依旧或者，无限重试，不断等待。
2. 直接认为B挂掉了，进行错误处理。

选择1，破坏了系统的活性，因为在重试的时间内，系统是无法对外提供服务的，也就是短暂得失活了。

选2呢又破坏了安全性，因为如果B其实没有挂掉，而这时候重新启动一个节点负责原本B的工作，那么此时系统中就会有旧的B节点，和新的B节点。此时旧的节点就称之为僵尸节点（Zombie）。而如果在主从分布的系统，也就是一个leader多个follower的系统中，如果B刚好是leader，那么这种情况也被称之为脑裂。

可以发现，liveness和响应速度有关，而satefy又和系统的可用性相关，并且这两者是不可兼得的。

关于这个问题，上世纪Lynch发表的一篇论文《Impossibility of Distributed Consensus with One Faulty Process》，基本上已经阐述了这个定理，也就是FLP impossibility。

FLP impossibility

FLP impossibility说明了这样一件事，在分布式或者说异步环境下，即便只有一个进程（节点）失败，剩余的非失败的进程不可能达成一致性。

这个是分布式领域中的定理，简称就是FLP impossibility。

当然所有的定理似乎都不是那么好理解，FLP impossibility也是一样，光是结论听起来就非常拗口。证明起来那就更加抽象，甚至在论文中也没有通过例子来论证。因为如果要通过实例来论证，那么首先就得要先设计N多的分布式算法，然后再逐一证明这些算法是FLP impossibility。

其实通俗些的理解，那就是说分布式（异步）环境下，liveness和satefy是鱼与熊掌不可兼得。不可能做到100%的liveness同时又兼顾到satefy。想要100%的satefy，那么liveness又保证不了，这里面又好像有CAP的影子，不得不说道路都是相通的。

话说回来，既然FLP impossibility已经说死了，异步环境下，即便只有一个进程（节点）失败，剩余的非失败的进程不可能达成一致性，那么paxos和raft这些算法又是如何做到分布式异步环境下一致的呢？

柳暗花明

其实FLP impossibility已经为我们指明方向了。既然无法完全兼得，那自然要放松某方面的限制，satefy是不能放松的，那自然只能从liveness上下手了。

具体做法上，那就是给分布式系统加上一个时间限制，其实在前面介绍liveness和satefy的时候，应该就有人能想到了。既然不能一直等待也不能直接任务远端节点挂掉，那么折衷一下，在某个时间内不断重连，超过这个时间，则认为远端节点是挂掉就可以了。

而事实上也正是如此，如果你对zookeeper熟悉，那应该知道zookeeper在选举leader的时候是不提供服务的，这就是它丧失部分liveness的一个体现。另一个体现是，性能，因为要通过一个时间段来对远端节点状态进行确认，那自然性能会有所下降，这又是不可避免的。

而具体的raft算法，那就等到下一节再说吧。

总结：

1. 分布式一致性指的其实就是分布式异步环境下，要让多个节点对系统状态的改变能够达成共识。
2. 分布式系统一致性难，难在异步通信不可靠。由此衍生出了liveness和satefy取舍的问题以及僵尸节点问题，有了FLP impossibility定理。
3. paxos/raft等算法通过一个安全时间段，可以在某种程度上实现分布式系统的一致性。

PS：本篇大部分参考自端到端一致性,流系统Spark/Flink/Kafka/DataFlow对比总结，只是里面有很多是讲流处理系统的。不过同样是裂墙推荐，反正看过的都说好。

以上~