一致性算法Raft 简易入门

当我们只有一个服务节点的情况下，是不存在节点共识的问题的，当存在多个不同服务节点时，才会引入分布式一致性的问题。

Raft是一种实现分布式共识的协议。所谓共识，就是多个节点对某个事情达成一致的看法，即使是在部分节点故障、网络延时、网络分割的情况下。

主要应用场景：

主要解决什么问题？

分布式存储系统通常通过维护多个副本来提高系统的可用性，带来的代价就是分布式存储系统的核心问题之一：维护多个副本的数据一致性。

为了提高理解性，Raft将一致性算法分为了几个部分，包括领导选取（leader selection）、日志复制（log replication）、安全（safety），并且使用了更强的一致性来减少了必须需要考虑的状态。

本文通过一个小故事做示例，来便于大家快速理解。

从以上选举流程可以发现，一个节点任一时刻肯定处于以下三状态之一：

这三个状态的转移过程如下图所示：

选举过程

Log Replication（日志复制）

经过Leader选举流程，产生了新的Leader节点，系统的所有变更都要通过Leader节点来实现。

log-based replicated state machine示意图：

关于应用过程中的几个问题

为了保证团队运行的稳定，有几个默认的要求：

即任一任期内最多一个leader被选出。假如系统中同时有多于一个leader，被称之为脑裂（brain split），这会导致数据的覆盖丢失。

在raft中，两点保证了这个属性：

1）一个节点某一任期内最多只能投一票；

2）只有获得majority投票的节点才会成为leader。

Leader将客户端请求封装到一个个的log entry，将这些log entries复制到其他Follower节点，大家按顺序应用这些请求，那最终状态肯定是一致的。

Raft日志同步结论：

1）如果不同日志中的两个条目有着相同的索引和任期号（term），则它们所存储的命令是相同的。

2）如果不同日志中的两个条目有着相同的索引和任期号（term），则它们之前的所有条目都是完全一样的。

如果一个log entry 在某个任期被提交，那么这条log一定会出现在所有更高term的leader的日志里面。

Raft日志覆盖规则：

1）一个日志被复制到majority节点才算committed

2）一个节点得到majority的投票才能成为leader，而节点A给节点B投票的其中一个前提是，B的日志不能比A的日志旧。

所有的算法实现原理，其实都是真实社会工作模式的影射，联系生活中的实际案例来理解复杂的一致性算法，可以让我们达到事半功倍的效果。

本文是让大家对raft协议有一个简单了解入门，如有兴趣去更深入了解，推荐给大家两个不错的链接：

1）Raft可视化测试以及各语言版本实现的Raft：https://raft.github.io/

2）Raft算法-动画演示（很好的入门教程）：http://thesecretlivesofdata.com/raft/