分布式系统一致性问题与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对比总结，只是里面有不少是讲流处理系统的。不过一样是裂墙推荐，反正看过的都说好。

以上~