很有意思的Raft原理，带你动画还原，后面附带具体ETCD示例，欢迎来戳~~

前言

高能预警，本文是我今年年初写了，当时花了一个月时间，所以内容会比较长，其中的Raft协议非常硬核，由于当时对文章排版不熟练，所以可读性不高，现在对文章重新整理，提炼了比较核心的内容。

我相信90%的读者不会一口气看完，虽然文章精简了，但是还是比较长，只是希望想日后想学习ETCD的同学，或者面试前需要了解的同学回头翻一下就够了，那么我写这篇文章的意义就有了。

也不多BB，直接开整。

走进ETCD

什么是ETCD

etcd是一个Go言编写的分布式、高可用的一致性键值存储系统，用于提供可靠的分布式键值存储、配置共享和服务发现等功能，具有以下特点：

• 简单：

• 易使用：基于HTTP+JSON的API让你用curl就可以轻松使用；
• 易部署：使用Go语言编写，跨平台，部署和维护简单。

• 可靠：

• 强一致：使用Raft算法充分保证了分布式系统数据的强一致性；
• 高可用：具有容错能力，假设集群有n个节点，当有(n-1)/2节点发送故障，依然能提供服务；
• 持久化：数据更新后，会通过WAL格式数据持久化到磁盘，支持Snapshot快照。

• 快速：每个实例每秒支持一千次写操作，极限写性能可达10K QPS。
• 安全：可选SSL客户认证机制。

ETCD框架

从etcd的架构图中我们可以看到，etcd主要分为四个部分：

• HTTP Server：用于处理用户发送的API请求以及其它etcd节点的同步与心跳信息请求。
• Store：用于处理etcd支持的各类功能的事务，包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等，是etcd对用户提供的大多数API功能的具体实现。
• Raft：Raft强一致性算法的具体实现，是etcd的核心。
• WAL：Write Ahead Log（预写式日志），是etcd的数据存储方式。除了在内存中存有所有数据的状态以及节点的索引以外，etcd就通过WAL进行持久化存储。WAL中，所有的数据提交前都会事先记录日志。Snapshot是为了防止数据过多而进行的状态快照；Entry表示存储的具体日志内容。

Raft协议

基本概念

名词解释

Raft协议一共包含如下3类角色：

• Leader（领袖）：领袖由群众投票选举得出，每次选举，只能选出一名领袖；
• Candidate（候选人）：当没有领袖时，某些群众可以成为候选人，然后去竞争领袖的位置；
• Follower（群众）：这个很好理解，就不解释了。

然后在进行选举过程中，还有几个重要的概念：

• Leader Election（领导人选举）：简称选举，就是从候选人中选出领袖；
• Term（任期）：它其实是个单独递增的连续数字，每一次任期就会重新发起一次领导人选举；
• Election Timeout（选举超时）：就是一个超时时间，当群众超时未收到领袖的心跳时，会重新进行选举。

角色转换

这幅图是领袖、候选人和群众的角色切换图，我先简单总结一下：

• 群众 -> 候选人：当开始选举，或者“选举超时”时
• 候选人 -> 候选人：当“选举超时”，或者开始新的“任期”
• 候选人 -> 领袖：获取大多数投票时
• 候选人 -> 群众：其它节点成为领袖，或者开始新的“任期”
• 领袖 -> 群众：发现自己的任期ID比其它节点分任期ID小时，会自动放弃领袖位置
• 备注：后面会针对每一种情况，详细进行讲解。