Etcd是什么
Etcd 是一个分布式的,一致的 key-value 存储,主要用途是共享配置和服务发现。Etcd 已经在很多分布式系统中得到广泛的使用。
etcd
为什么需要 Etcd ?
所有的分布式系统,都面临的一个问题是多个节点之间的数据共享问题,这个和团队协作的道理是一样的,成员可以分头干活,但总是需要共享一些必须的信息,比如谁是 leader, 都有哪些成员,依赖任务之间的顺序协调等。所以分布式系统要么自己实现一个可靠的共享存储来同步信息(比如 Elasticsearch ),要么依赖一个可靠的共享存储服务,而 Etcd 就是这样一个服务。
Etcd 提供什么能力?
Etcd 主要提供以下能力,已经熟悉 Etcd 的读者可以略过本段。
提供存储以及获取数据的接口,它通过协议保证 Etcd 集群中的多个节点数据的强一致性。用于存储元信息以及共享配置。
提供监听机制,客户端可以监听某个 key 或者某些 key 的变更(v2 和 v3 的机制不同,参看后面文章)。用于监听和推送变更。
提供 key 的过期以及续约机制,客户端通过定时刷新来实现续约(v2 和 v3 的实现机制也不一样)。用于集群监控以及服务注册发现。
提供原子的 CAS(Compare-and-Swap)和 CAD(Compare-and-Delete)支持(v2 通过接口参数实现,v3 通过批量事务实现)。用于分布式锁以及 leader 选举。
更详细的使用场景不在这里描述,有兴趣的可以参看文末 infoq 的一篇文章。
Etcd 如何实现一致性的?
说到这个就不得不说起 raft 协议。但这篇文章不是专门分析 raft 的,篇幅所限,不能详细分析,有兴趣的建议看 raft 协议的一个动画。便于看后面的文章,我这里简单做个总结:
raft 通过对不同的场景(选主,日志复制)设计不同的机制,虽然降低了通用性(相对 paxos),但同时也降低了复杂度,便于理解和实现。
raft 内置的选主协议是给自己用的,用于选出主节点,理解 raft 的选主机制的关键在于理解 raft 的时钟周期以及超时机制。
理解 Etcd 的数据同步的关键在于理解 raft 的日志同步机制。
Etcd 实现 raft 的时候,充分利用了 go 语言 CSP 并发模型和 chan 的魔法,想更进行一步了解的可以去看源码,这里只简单分析下它的 wal 日志。
wal 日志是二进制的,解析出来后是以上数据结构 LogEntry。其中第一个字段 type,只有两种,一种是 0 表示 Normal,1 表示 ConfChange(ConfChange 表示 Etcd 本身的配置变更同步,比如有新的节点加入等)。第二个字段是 term,每个 term 代表一个主节点的任期,每次主节点变更 term 就会变化。第三个字段是 index,这个序号是严格有序递增的,代表变更序号。第四个字段是二进制的 data,将 raft request 对象的 pb 结构整个保存下。Etcd 源码下有个 tools/etcd-dump-logs,可以将 wal 日志 dump 成文本查看,可以协助分析 raft 协议。
raft 协议本身不关心应用数据,也就是 data 中的部分,一致性都通过同步 wal 日志来实现,每个节点将从主节点收到的 data apply 到本地的存储,raft 只关心日志的同步状态,如果本地存储实现的有 bug,比如没有正确的将 data apply 到本地,也可能会导致数据不一致。