从majority voting解读Raft

- 日理万妓 2023-02-23 05:15 1阅读 0赞

### 从majority voting解读Raft ###

*   *  Raft
     *  状态机复制方法
     *  分布式问题
     *  majority voting
     *  leader租约
     *  投票实现
     *  故障恢复

## Raft ##

Raft是一个分布式一致性协调算法，采用状态机复制方法和majority voting选举算法。

## 状态机复制方法 ##

分布式计算的目的之一是容灾备份，也就是当某一台机器故障，其他机器可以接管其工作，而保证系统的持续稳定运行。  
在这种需求下，为了使得每一个机器都可以作为一个完整备份，接管整个系统的工作，我们会共享整个系统的完整数据或者完整状态到不同机器上。  
对于共享完整数据的做法，即备份，因为需要实时复制完整数据，效率低下，且不能利用分布式计算隔离计算的优势.  
而状态机复制方法是指，只要不同机器都处于同一状态，即可完成接管工作。状态具体就如事务，每当系统里产生了事务，把所有事务分发给系统中所有机器，事务的执行由每台机器自行保证，并且异步隔离执行，则机器具备最终一致性。

## 分布式问题 ##

分布式计算，即由多个机器一起负责计算，每个机器知道环境下所有机器信息，互相通信协调。

分布式机器计算带来的好处就是，机器可以多点布置，比如机器A在城市1机器B在城市B，这样如果城市1出现灾难导致机器A所在机房受损，仍有位于其他城市的机器B可以作为备份，保证服务的不停止。

而分布式也带来了一系列的问题。因为系统为多机器共同运作，当网络故障等原因，可能出现网络分区隔离（城市间、机房间、机器间不能通信等状况），或者因节点故障、快速恢复造成的实时数据不一致。

如下图，s1和s2为两台服务端机器，互相协调进行分布式计算。c1和c2分别为两个客户端。s1和s2都是同等角色，因为为了提供容灾能力，我们允许客户端与任一服务端机器(s1\\s2)通信，执行系统功能请求。  
![无leader][leader]  
这个结构下存在的问题是，当c1向s1发送一条事务A，c2向s2发送事务B，此时双方进行协调通信，将无法确定事务A与事务B的执行顺序（对于s1是先执行事务A，对于s2是先执行事务B）,这时假设我们通过某一规则来规定事务顺序，比如数字编号小的优先（s1大于s2），所以我们可以在编号大节点产生事务时，将事务传递给最小编号节点，由最小编号节点来通知其他节点执行，通过单机判定保证顺序性。此时的最小编号节点也就是系统的协调者，一般也叫为leader。

但是这种过于简单的选举算法，将带来脑裂的问题，比如上述结构，c1与s1在同一网络分区，c2与s2在另一网络分区。因为网络故障，导致两个网络分区不可通信。则此时s1认为s2故障，c1的事务s1正常执行。s2认为s1故障，c2的事务，s2正常执行。这就导致了一个分布式系统中的机器不一致，对于两个不同客户端，存在两个不同状态，提供不同的结果。s1和s2都各自认为自己是leader，特别是，当c1和c2代表同一个客户端在不同时刻使用不同网络时，那将更加糟糕（客户端的顺序操作，被分离为两部分隔离操作，分别执行在两个不同的服务端机器，导致结果不正确）。  
![脑裂][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDYyNzk4OQ_size_16_color_FFFFFF_t_70]  
所以分布式系统有个典型的CAP理论，即一致性、可用性、分区容错性三者往只能取两者而弃其一（因为分区容错性比较重要，一般在可用性和一致性间权衡）。

## majority voting ##

majority voting即投票结果多数同意规则，也就是当某个决定出现分歧时，由大多数人（超过一半）做的决定作为最终决定。比如选举leader需要半数以上的机器投票给leader，同样，当一个事务要提交执行，至少需要收到半数以上机器的执行通过，才能最终确认为已执行并响应成功。通过这个半数准则，可以解决分布式的脑裂等问题。

分布式一致性协调最常出现的就是因为网络分区等原因，出现通信隔离而产生脑裂（多个leader）。而因为规则的限定必须是大多数（初始投票者数量的一半以上），则可以成为leader的节点只能有一个，并且保证了，新的leader所在分区，必定存在一个机器与旧leader离线前处于同一网络分区（同步了旧leader的最完整事务备份）。

所以， 在脑裂出现后，网络分区内机器不足一半以上的脑裂半区，永远不能执行事务和选出leader，通过majority voting可以确定一个leader选区。然后，为了确定具体机器，Raft会在选区中选举保存的事务最完整（选举版本号最高之后，事务数量最多的一台机器）的一台机器（因为每一轮选举结束会使得当前网络分区内的机器保存的选举版本号+1，一开始从1开始，而每台机器保存的事务，可能是客户端提交上来，还未提交leader执行的。而使用高选举版本号优先是因为，即便事务数量多（存在高选举版本号机器不具备的事务），但是选举版本号低，代表其并没有获得后面几轮的选举胜利，因为半数投票原则，这些事务也没办法执行，所以分布式系统都是在选举执行后，采告知客户端事务成功，所以该事务是一个废弃事务，可以忽视（没有告知客户端执行成功，只存在于当前机器中））。

因此，一个 2n+1台机器的分布式系统，在这种情况下，可以最多容许n次故障（因为2n+2也是n次，所以一般节省成本，就默认系统最好为2n+1）。因此一个使用majority voting分布式系统，至少需要有3台机器，才有意义（一次故障容忍能力）。  
![3台机器][3]

## leader租约 ##

因为频繁的与leader通信，检测是否出现故障，需要重新选举将极大提高系统损耗，所以一般会为leader设定一个租约时间。当租约到期后，如果follower机器（非leader）没有收到leader发来的续租申请，则会发起重新选举。同样的，leader租约到期后，主动发送的续租申请如果没有收到超过半数以上的机器同意，也应主动放弃leader身份，进入重新选举状态。通过租约，极大降低通信频率。

## 投票实现 ##

majority voting的投票，可以通过泛洪法，每台机器向能通信到的所有机器（同个网络分区下）投自己一票，当收到事务更完整（选举版本号最高之后，事务数量最多的一台机器）的投票时，改为投票给该机器。这样当一台机器在一轮投票中收到超过半数的投票时，即可告知其他机器，其已经当选leader，结束投票。而不足一半以上机器的网络分区，最终结果就是环境一致处于投票状态，无法提供服务（丢失可用性，保证一致性与分区容错性），直到网络恢复，进入故障恢复。

## 故障恢复 ##

当网络分区故障恢复，或者机器故障恢复重启时，其会与所有机器通信，得知leader后，告知leader自己保存的事务和之前的选举轮次，leader则根据情况，发送某个事务执行结果往后的所有事务给该机器，使得该机器恢复到与当前leader相同状态。重新加入分布式集群，成为follower。

更多文章，请搜索公众号歪歪梯Club  
![更多资料，请搜索公众号歪歪梯Club][Club]

[leader]: https://img-blog.csdnimg.cn/20200705171913962.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDYyNzk4OQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDYyNzk4OQ_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200705174526471.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDYyNzk4OQ==,size_16,color_FFFFFF,t_70
[3]: https://img-blog.csdnimg.cn/20200705172827773.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDYyNzk4OQ==,size_16,color_FFFFFF,t_70
[Club]: https://img-blog.csdnimg.cn/20200521183346518.jpg