看图轻松了解etcd

用一些图示结合场景和文字轻松了解etcd，文章是针对etcd初学者的，目的是让你们了解etcd是什么、主要在什么场景下使用、etcd集群是怎么工做的以及建立集群时应该如何选择集群的节点数。算法

etcd 是一个高可用强一致性的键值仓库在不少分布式系统架构中获得了普遍的应用，其最经典的使用场景就是服务发现。安全

做为一个受到 ZooKeeper启发而催生的项目，它除了拥有与之相似的功能外，更专一于如下四点。markdown

简单：易于部署，易使用。基于 HTTP+JSON 的 API 让你用 curl 就能够轻松使用。
安全：可选 SSL 客户认证机制。
快速：每一个实例每秒支持一千次写操做。
可信：使用一致性 Raft 算法充分实现了分布式。

etcd 的场景默认处理的数据都是系统中的控制数据。因此etcd在系统中的角色不是其余NoSQL产品的替代品，更不能做为应用的主要数据存储。etcd中应该尽可能只存储系统中服务的配置信息，对于应用数据只推荐把数据量很小，可是更新和访问频次都很高的数据存储在etcd中。架构

服务发现（Service Discovery）

服务发现要解决的是分布式系统中最多见的问题之一，即在同一个分布式集群中的进程或服务，要如何才能找到对方并创建链接。本质上来讲，服务发现就是想要了解集群中是否有进程在监听 udp 或 tcp 端口，而且经过名字就能够查找和链接。要解决服务发现的问题，须要有下面三大支柱，缺一不可。curl

一个强一致性、高可用的服务存储目录。基于 Raft 算法的 etcd 就是一个强一致性高可用的服务存储目录。tcp
一种注册服务和监控服务健康状态的机制。用户能够在 etcd 中注册服务，而且对注册的服务设置 key TTL，定时保持服务的心跳以达到监控健康状态的效果。分布式
一种查找和链接服务的机制。经过在 etcd 指定的主题（由服务名称构成的服务目录）下注册的服务也能在对应的主题下查找到。oop

etcd的核心组件

从 etcd 的架构图中咱们能够看到，etcd 主要分为四个部分。url

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

一般，一个用户的请求发送过来，会经由 HTTP Server 转发给 Store 进行具体的事务处理，若是涉及到节点的修改，则交给 Raft 模块进行状态的变动、日志的记录，而后再同步给别的 etcd 节点以确认数据提交，最后进行数据的提交，再次同步。spa

用户从集群中哪一个节点读写数据？

为了保证数据的强一致性，etcd集群中全部的数据流向都是一个方向，从 Leader （主节点）流向 Follower，也就是全部 Follower 的数据必须与 Leader 保持一致，若是不一致会被覆盖。

简单点说就是，用户能够对etcd集群中的全部节点进行读写，读取很是简单由于每一个节点保存的数据是强一致的。对于写入来讲，etcd集群中的节点会选举出Leader节点，若是写入请求来自Leader节点便可直接写入而后Leader节点会把写入分发给全部Follower，若是写入请求来自其余Follower节点那么写入请求会给转发给Leader节点，由Leader节点写入以后再分发给集群上的全部其余节点。

下面的图示中一、3节点都有写入请求，节点1为Leader因此3的写入请求会转发给1，写入完成后再同步给全部节点。

如何选举Leader节点

假设集群中有三个节点，集群启动之初节点中并无被选举出的Leader。

Raft算法使用随机Timer来初始化Leader选举流程。好比说在上面三个节点上都运行了Timer（每一个Timer的持续时间是随机的），第一个节点率先完成了Timer，随后它就会向其余两个节点发送成为Leader的请求，其余节点接收到请求后会以投票回应而后第一个节点被选举为Leader。

成为Leader后，该节点会以固定时间间隔向其余节点发送通知，确保本身还是Leader。有些状况下当Follower们收不到Leader的通知后，好比说Leader节点宕机或者失去了链接，其余节点会重复以前选举过程选举出新的Leader。

判断写入是否成功

etcd认为写入请求被Leader节点处理并分发给了多数节点后，就是一个成功的写入。如何界定多数节点呢？很简单，假设总结点数是N，那么多数节点 Majority=N/2+1，不过在etcd中使用的术语是 Quorum而不是 Majority。因此界定多数节点的公式是 Quorum=N/2+1。

关于节点数的最佳实践

关于如何肯定etcd集群应该有多少个节点的问题，上图的左侧的图表给出了集群中节点总数(Instances)对应的Quorum数量，用Instances减去Quorom就是集群中容错节点（容许出故障的节点）的数量。

因此在集群中推荐的最少节点数量是3个，由于1和2个节点的容错节点数都是0，一旦有一个节点宕掉整个集群就不能正常工做了。

当决定集群中节点的数量时，强烈推荐奇数数量的节点，好比下图表中高亮的那几个选项。

具体来讲，6个节点的集群它的容错能力并无比5个节点的好，他们的容错节点数同样，一旦容错节点超过2后，因为Quorum节点数小于4整个集群也变为不可用的状态了。

因此在决定集群中的节点数时，奇数要优于偶数。

因为etcd以前接触的很少网上成体系资料也比较少一开始理解起来有些困难，最近看了很多文章同时偶然在Youtube上发现了一个介绍etcd入门的视频，以为很好。文中的图片大部分都是来自视频的截图，推荐能访问油管的同窗都去看看，比看我这里的文章更易懂。若是英语听力不太好的同窗能够先看看个人文章再去油管上看视频。

视频连接 www.youtube.com/watch?v=L9x…