分布式一致性

在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性。

分布式一致性算法

比较常见的一致性算法包括Paxos算法，Raft算法，ZAB算法等

Raft算法使用场景

一般用作两种场景： 元数据管理 ：比如etcd，特点是数据规模小，主要保证数据一致性和集群的高可用（raft选主）,所以一套raft集群就够了。 分布式数据库 ：这种会用partition group，每个group有一个raft集群，当数据变大的时候会做扩展。

Raft算法基础

Raft把算法流程分为三个子问题：领导选举（Leader election）、日志复制（Log replication）、安全性（Safety）。

角色

Raft算法中在任意时刻最多只有一个Leader，正常工作期间只有Leader和Followers。

状态转换

状态切换流程：

任期

任期 ：可以理解为是节点担任Leader职务的时间期限。

Raft 将时间划分为一个一个的任期（term），每个任期由单调递增的数字（任期编号）标识，工作期可长可短也可能不存在

通信

中 服务器节点之间通信通过两个 RPC 调用：

Leader选举

初始状态

初始状态时，每个节点的角色都是 Follower(跟随者)，Term任期编号为 1(假设任期编号从1开始)

不过这两种情况会触发选举：

选举

既然有两种情况下会触发选举，一个是初次启动，一个是Leader故障未发送心跳给Follower，那么我们假设有五个节点，然后分别用图来看下是如何选举的！

初次启动时：

初次启动节点都是正常流程如下：

Leader故障时：

Node2此时是Leader 节点，结果故障了，剩下四个节点参与选举。

当选条件

在一个任期（Term）内只可以投票给一个结点，得到超过半数的投票才可成为 Leader，从而保证了一个任期内只会有一个 Leader 产生。

日志同步

概括成一句话就是： 保证Leader上日志能完全相同地复制到多台Follower服务器上。

OK！我们看下是如何进行同步的

日志结构

Raft算法中，每个节点维护着一份日志，其中包含了系统中所有状态变更的记录，每一次状态变更被称为一个日志条目。

我们先看日志结构和右侧说明：

图中每个节点存储自己的日志副本(log)，每条日志记录包含：

•索引 (log index)：记录在日志中的位置，是一个连续单调递增整数

•任期号 (term)：日志记录被创建时Leader的任期号，上图中有三个任期

•命令 (command)：客户端请求指定的、状态机需要执行的指令

执行流程

了解完日志结构后，我们来看日志是如何发起同步的。

日志持久化存储的条件

Follower节点必须先将记录安全写到磁盘，才能向Leader节点返回写入成功响应。

如果一条日志记录被存储在超过半数的节点上，我们认为该记录已提交(committed)——这是 Raft 非常重要的特性！如果一条记录已提交，意味着状态机可以安全地执行该记录

流程如下图：

一致性检查

日志一致性

Raft算法的目的是保证所有节点的一致性，即一个日志条目在某个节点被提交，那么这个日志条目也必须在所有节点上被提交。

总结

Raft算法是一种简洁而高效的分布式一致性算法，通过引入Leader选举和日志复制的机制，确保了分布式系统的共识和一致性。