分布式共识算法之raft算法介绍

前言

raft算法是什么：raft是一个共识算法，所谓共识，就是多个节点对某个事情达成一致的看法。

使用场景

我们直接看来raft算法可以解决什么问题，比如在分布式场景下，我们的中间件为了达到高可用，那么必定不可能是单体架构，那么有一种常见的架构就是leader-follower架构，如nacos的高可用架构就是采用的raft算法，如下图

使用一个leader和两个follower组成一个高可用的架构模型

leader和follower的定义如下：

1. leader：负责处理写请求，可以理解为是该架构的主要负责人
2. follower：可以理解为备胎，不能处理写请求，当leader节点挂掉之后可以顶替成为leader

那么有个问题是为什么只有leader可以处理写请求，而不是所有节点都可以处理写请求呢？

原因是在该架构下需要涉及到数据的同步，如果所有节点都可以处理写请求，那么就需要互相同步数据，那么数据有可能发生错乱，数据将不能保持一致性

那么在该架构下主要涉及到了哪些要解决的问题呢
1、leader的选举，即谁可以成为leader
2、数据的同步，数据必须保持一致性，即leader的数据需要同步到follower

raft算法就是为了解决上面这两个问题的
最后附上一个raft的动画，可以形象的展示raft的整个过程
http://thesecretlivesofdata.com/raft

这里需要单独说下raft的数据同步也是依赖2PC（二阶段提交）的
主要流程是

1. leader接收到写请求，把当前写请求记录到日志文件中，但是并没有更新到本地数据中
2. 然后向所有follower节点发起预提交操作，此时follower也会记录到日志中，也不会更新到数据
3. leader如果收到超过一半的响应是成功（过半请求主要是避免某个follower挂掉后导致阻塞），那么就会提交本地事务，并且返回客户端成功，然后再发送请求告诉follower节点可以提交事务了
4. 如果第3步有follower节点挂掉了而没有响应leader，那么在follower节点重启后会自动同步leader的最新数据，以此来达到数据的最终一致性

注意这里raft算法同步数据的方式是过半提交，不是强一致性方案，即也是存在当服务端返回成功后，后续有请求访问到还未成功更新到数据的follower节点导致数据短暂的不一致性

总结

raft算法在leader选举的场景比较多，如

• nacos的高可用结构
• redis sentinel的高可用结构
• etcd的raft算法