RAFT: 分布式系统&PAXOS 理解

什么是分布式系统：
        一个由多台机器在一个可以互联的网络中搭建的集群系统。

为什么要分布式系统：
       早在1946年，美国的宾夕法尼亚大学里，莫克利和艾克特两个人为了进行弹道计算，组装了世界上第一台计算机ENIAC，每秒钟可以进行5000次运算。这段信息我们可以得出什么？计算机起因是用于计算的，早期的技术原因使得计算机的计算能力很低。
       随着人们的欲望推动着计算机的不断发展，计算机作为计算的属性变得越来越强。现代计算机运算速度最快的是中国国防科学技术大学研制的“天河二号“，每秒33.86千万亿次浮点数计算荣居榜首。这个是超级计算机系列中的top机型。而作为普通人，使用的计算机如果主频是1GHZ，那么就是10万亿/秒的计算速度，按照这个计算速度，在cpu中计算i++，每秒可以计算到10w亿，这是一个很大的计算速度。i++只是简单的计算，稍微复杂一点的，再涉及到内存交互、IO等过程，计算机的工作效率就会大大降低。一台普通的pc机器，支撑较为复杂的操作最多可以达到万级别的qps，服务器类型机器稍微牛一点，可以达到几十万的qps，即使这样，单机也不能支撑在中国范围内14亿人口的并发请求。分布式最初要解决的问题，就是服务支撑问题。
       而随着研究人员的不断深入以及互联网的不断发展，各方面的需求越来越多，公司基于利己的问题考虑，使用分布式系统解决的就不仅仅是服务支撑问题了。比如服务容灾、数据安全等等，这里就不扩展出去了。

分布式系统搭建会遇到什么问题：
       分布式系统是由多台机器搭建的可以互联的系统。 这里又可以分为三种情况，一种相互互联，一种部分相互互联，一种均不互联。
       均不互联是一种无状态的场景，集群可以任意扩缩容，且扩容对集群无较大的压力。另外两种情况均为有状态的场景，其中部分相互互联场景更加特殊，且实现方式也多种多样，不过其与相互互联场景相似度很大，我们就拿相互互联来聊一聊。
       在相互互联场景下，当集群对外提供服务时候，最大的问题就是一致性问题。我们假设有一个集群S，里面有3个节点a、b、c，每个节点都可以对外提供读写服务，这时候有10个请求过来，均需要对x进行x+1操作，那么在任意节点都可以提供读写的情况下，很容易发生一个问题，x的最终值不是x+10，导致这个问题的本质原因就是数据的一致性问题。为了解决一致性问题，我们再往更深层次思考，集群在面对每个请求的时候，先对该次请求达成共识，再进行处理，这样不就可以解决一致性的问题了？ 但是难点就在于怎么达成这个共识，而达成这个共识，时间成本会不会难以接受，也就是分布式面对的第二个问题，可用性问题。最后一个问题也是最容易想到的一个，那就是如果某一个机器挂了，会不会对服务有影响，这个就是分区容错性问题了。
       由上我们可以看到，在互联场景下，会出现三大问题：一致性、可用性、分区容错。为了分析这个问题，我们提出了CAP理论。详见下节。

什么是CAP理论：
       C：consistent，A：available，P：partition tolerance，以上就是对CAP拆开的英文解释，从英文上来看，就是上篇所说的三个问题。在CAP理论里面，P是很孤立的，因为只要有多机器出现，就会存在分区容错问题，这个也是一定需要保证的，不然分布式系统的意义就没了。另外两个CA，就是一对冤家了。
       为什么说CA是一对冤家了。可以再看看我在上一节分析中的场景，从场景中我们可以得知，如果需要保证一致性，就得牺牲可用性。因此在分布式实践里面，系统多围绕着CA做研究，提出的系统要么偏向C，要么偏向A。著名的redis设计就是一款偏向A的设计，而paxos就是一款偏向C的理论。

PAXOS-basic paxos：
       前面提到过，paxos是lamport提出的一个分布式共识理论。提到共识，需要保证集群中的机器有一个共同的结论，这样才能保证服务的一致性。paxos在集群共识上，提出了一个最基本的模型，我们叫它basic paxos。
       basic paxos 给集群的每个机器都分配了其相应的角色。client、proposer、acceptor、learner。client：提交结案请求的机器，可以理解为请求服务的客户端；proposer：接收结案请求的机器，可以理解集群对外的一个窗口，相当于接待员；acceptor：对结案商议审批的机器，可以理解为国会会议员；learner：可以理解为国家各部门机构，在国会决议了某个结案后，各部分得到信息，普通人就可以通过部门获取到信息，当然也可以通过国会直接获取信息，如果国会的机器不忙的话。可以看到basic paxos其实是把国家工作的流程搬到了线上，这个流程看着是很好，但是里面也有很多问题。
       1. 如何保证提案被大家一致认可提交
       2. 如何保证集群在出现部分失败的时候，也能提交提案
       3. 如何保证提案的顺序性
       对于第一个问题，需要保证集群内的机器节点可以互联。当一个proposer节点接到提案请求后，需要将信息分发给acceptors，当大家都觉得可以提交的时间，就会告知proposer该提案可以被接受。proposer一旦收到大家接受提案的信息后，会发一个消息告知所有acceptor，提交提案。可以看到这里面要提交一个commit需要进行二次沟通，在学术上被称为二阶段提交（2PC）：第一次提出提案，供大家审议；第二次，审议通过，则告知提交提案，不通过则撤销提案。这里我们分析下为什么要用2PC，如果只是1PC的话会出现什么问题呢？如果说提案最后都通过了，那么问题不大，当提案最后没通过，会出现什么问题呢？假如a通过，b、c不通过，我们使用1PC，则a会标记该提案是已经通过的提案，该提案就可以被访问了，然而事实上该提案是没有通过的，这样导致的不一致性问题是致命性的。2PC看起来还是可以保证一致性的，但是也有一些问题。同步阻塞、单点故障、数据不一致等问题（详见https://blog.csdn.net/skyie53101517/article/details/80741868）。所以还是需要其它手段来辅助保证一致性，我们继续往后讲。
       对于第二个问题，在集群部分失败的时候，怎么能保证提案的提交呢？basic paxos提出在多数节点认可后，提案就可以提交的策略。什么事多数呢？比如一个集群有3个机器，2就代表多数了；如果有4个机器，2也是代表多数，这里可以看到3和4能力上是差不多的，但是更耗费资源，因此业界更多的会使用奇数个机器来完成一致性集群的搭建。
       对于第三个问题，basix paxos要求每一个提案都需要带一个编号，这个编号是跟进请求顺序逐渐增加的，且不能重复。在这个条件下，basic paxos要求acceptor只能处理当前机器中收到的带有最大编号的提案，如果一个提案编号小于当前正在处理or已经处理过的某个提案，则丢弃。
       基于这三个问题所做的一些限制要求，分布式系统的一些功能慢慢就成型了。然而basic paxos也会存在一定的问题。比如上面说的会丢弃编号较小的提案，如果两个提案反复的向下图所示的方式提交，总是不能保证一个提案的原子性，反复被丢弃重试，就会出现活锁的情况。
       lamport在提出basic paxos的时候，同时提出了multi paxos。两者的区别在于，basic paxos对应的是单value场景，可以想到，如果只处理一个提案，上面所说的活锁基本就不会发生。然而现实中，并发是很常见的事情，因此multi paxos的提出针对的就是并发场景下的多value场景。我们看看multi paxos是如何做到的。

MULTI-PAXOS
       多valule是单value的集合，基于这样的视角，paxos在不断的有序的确定一个value，不就是多value场景了！multi-paxos把确定一个value的过程称为一个instance，它由proposer、acceptor、learner构成，如下图：
        multi-paxos引入了leader机制来解决提案冲突问题，leader节点作为唯一提议者，但是论文中，lamport并没有告知如何选举leader。当只有一个proposer来接受提案的时候，在单机中就可以保证提案不会出现冲突。
       mutli-paxos考虑到了basix paxos的复杂性，提出可以讲一些角色合并，比如没有必要单独把proposer拎出来，acceptor、learner只是机器角色问题，一个机器既可以做acceptor，也可以做leaner。基于以上的想法，proposer、acceptor、learner可以统称为server。
       multi-paxos也提出可以讲2pc改成1pc，减少机器间的交互成本。如下图，这个没有解决我上面所说的问题，如果提案失败了，出现了脏数据的场景。

RAFT&ZAB
       以上都是理论学家在做理论研究的过程中，提出的一些想法，但落到实地还是有很多问题。业界大佬们已经给我们实现了几款提供一致性分布式系统的算法，接下的几个内容我们就好好的研究下两个算法，raft&zab。基于raft的项目有很多，比如etcd等。zab则主要用在zookeeper中。zab和raft都是基于multi-paxos实现的，是一母多胞的兄弟。