分布式Raft算法介绍

 高可用性，高稳定性以及数据一致性是衡量服务的三个基本要素。其中数据一致性在分布式服务中是根基----不管是强一致性还是最终一致性等都需要保证其数据的一致性，不然高可用和高稳定没有任何意义（即便服务容忍一定时延的不一致）。

分布式一致性的保证：

数据保证一致性主要是这两种形式：一种是集群只有一个节点能进行数据的增删改，然后其它节点和单前节点进行同步数据。第二种就是集群节点通过沟通下在合适的时间大家一起进行数据的增删改数据来达到数据一致性。这两种方式细想下它们都需要有一个发起人，由发起人开个头然后集群开始数据的同步操作，这个发起人也就成为leader。

如何选leader比如：

方式一 ：大家都读数据库然后读取时增加读锁，谁获取了值就是leader，这种方式在获取锁时需要连接数据库，执行查询操作，增加锁，执行完操作后释放锁，同时还有单点问题，性能瓶颈，通过这种方式提供的锁服务无法满足需求，同时获取了锁的节点如果挂了呢？ 或者获取锁的节点在脑裂网络区间呢？ 这种方式选取leader不合适。

方式二：由一台服务器与所有机器保持心跳，当需要选择leader时 就在其中随机选择一台，同时通知所有的，如果超过半数同意就成功了。问题关键是一台服务器和所有机器保持心跳，为了提高高可用性增加备用机器，在这台机器挂掉后，备用机器需要和所有机器建立连接，为了提高速度，使用热备，master和热备也用心跳保持关系，一旦挂掉，就接过master的权限，执行其职能，同时客户机的配置中需要增加关于这两台机器的配置，方便为其创建连接，同时检测连接是否正常，这种方式就算出现脑裂问题也不影响，一切以连接到master机器上的所有节点为准。

方式三：集群中每个节点与其余所有节点共同商量谁来当leader。

目前业界使用的不管是Paxos还是Raft算法以及它们的变种算法都是采用方式三来进行leader选举。方式二有点资源浪费，但是按照常理来讲参与决策方越多效率越低，方式二却是避免了这种方式（暂时用不上）。

Raft算法由于其容易理解和实现等原因开始在后期大受欢迎比如：etcd就是基于此实现的，而大名鼎鼎的Kubernetes是基于etcd实现的（间接基于Raft），以及百度的braft（raft变种）。

Raft算法实现一致性通过实现下面：

》选择leader----这个是用来保证其是第一个执行操作的，保证独立性，不会在别的节点同时出现别的操作。

》日志复制----这是leader节点执行操作产生的操作日志，用来和leader节点保存一致，这是选举leader的原因，然后把日志复制到其余节点，每个节点执行成功以后就可以保证和leader节点保证一致了，这和传统的2pc（2 phase commit 2阶段提交） 优势在于---2pc在整个过程中是hold全部资源的，需要全部节点执行成功后才能释放而这个只需要leader节点执行成功，然后保存到日志并复制到别的节点后就可以了，其余节点什么时候执行，自有各个节点来保证日志的执行， 在leader任期内执行别的操作时必须 上一个执行的操作的log的日志已经分发到别的所有大部分节点了，不需要执行，只需要保存，后期执行就可以。

Raft这种算法选举时对性能有一定影响，不仅是Raft，其余的选举算法，随着节点的增加，选举的效率就越低，比如etcd就是建议部署3或5个节点就可以。如果需要大规模选举可以采用上面的方式二。（这就好比股票的撮合交易竞价或者是区块链中有比特币的公共链到联盟链等转换）。

问题：

选举时如何得知其获得了大多数选票，节点是会挂的，会随时变化：

当前节点参加选举时会和其余节点通讯，如果在通讯的大多数节点都同意，那就ok，那问题又来了，如何保障能和其它节点都能通讯？ 这个除非节点挂掉，如果在投后节点挂掉了也不影响，因为只能投给一个节点不能再投别的节点，投票前挂掉不没有影响。还有一种就是脑裂问题，这可能会在不同区域都选举一个区域的leader，对于脑裂问题 可以人工干预或者定时检查，对于脑裂区域是否不提供服务或者提供部分服务这个依据具体业务场景来。