共计 3040 个字符，预计需要花费 8 分钟才能阅读完成。
在分布式文件存储中，咱们通常会面临集群选主，配置共享和节点状态监控的问题。通过 etcd（基于 Raft 协定）能够实现超大规模集群的治理，以及多节点的服务可靠性。明天，咱们就聊聊 etcd 在分布式存储中的具体利用。
什么是 etcd ?
etcd 是由 CoreOS 公司开发的一个开源的分布式 KV 存储，次要用于服务发现、共享配置以及一致性保障。etcd 的灵感来自于 ZooKeeper 和 Doozer，但它更偏重以下几点：
- 简略：装置配置简略，反对 curl 形式的用户 API (HTTP+JSON)。
- 平安：可选反对 SSL 客户端证书验证。
- 疾速：依据官网提供的 benchmark 数据，单实例反对每秒 1w+ 写操作。
- 牢靠：采纳 Raft 算法，实现分布式系统数据的可用性和一致性。
为什么采纳 etcd ?
谈到 etcd，咱们未免会与 Zookeeper（以下简称 ZK）或 Consul 进行比拟，Consul 的可靠性和稳定性还须要工夫来验证（我的项目发起方本人也并未应用）；ZK 和 etcd 都是程序一致性的（满足 CAP 的 CP），这就意味着无论咱们拜访任意节点，都将取得最终统一的数据视图。比照 ZK，etcd 具备以下劣势：
- 一致性：etcd 应用 Raft 协定，简略易懂，而 ZK 应用 ZAB（类 paxos 协定 )，该协定以简单著称，尤其对初学者来说。
- 运维方面：etcd 比 ZK 更容易运维。
- 我的项目活跃度：etcd 社区比拟沉闷，代码贡献者超 700 人，目前始终在更新。而 ZK 社区相比活跃度不是那么高，代码贡献者 170 多人，版本很久没有更新。
- 接口方面：etcd 提供了 http + json，grpc 接口，反对跨平台。而 ZK 须要应用其专属客户端。
- 安全性：etcd 反对 https 拜访，ZK 在这方面缺失。
etcd 架构及工作原理
etcd 架构图
- 网络层 HTTP Server：用于解决用户发送的 API 申请以及其它 etcd 节点的同步与心跳信息申请。
- Raft 模块：Raft 强一致性算法的具体实现，是 etcd 的外围。
- Store 模块：波及 KV 存储、WAL 文件、Snapshot 治理等，用户解决 etcd 反对的各类性能的事务，包含数据索引节点状态变更、监控与反馈、事件处理与执行，是 etcd 对用户提供的大多数 API 性能的具体实现。
- 正本状态机：这是一个形象的模块，状态机的数据保护在内存中，定期长久化到磁盘，每次写申请都会长久化到 WAL 文件，并依据写申请的内容批改状态机数据。
etcd 工作原理
etcd 集群是一个分布式系统，由多个节点互相通信形成整体对外服务。每个节点都存储了残缺的数据，并且通过 Raft 协定保障每个节点保护数据的一致性。在 Raft 协定中，有一个强 leader，由它全权负责接管客户端的申请命令，并将命令作为日志条目复制给其余服务器，在确认平安后，将日志命令提交执行。当 leader 故障时，会选举产生一个新的 leader。在强 leader 的帮忙下，Raft 将一致性问题合成为三个子问题：
- Leader 选举：当已有的 leader 故障时必须选出一个新的 leader。
- 日志复制：leader 承受来自客户端的命令，记录为日志，并复制给集群中的其余服务器，并强制其余节点的日志与 leader 保持一致。
- 平安 safety 措施：通过一些措施确保零碎的安全性，如确保所有状态机依照雷同程序执行雷同命令的措施。
etcd 在分布式存储中的利用
对于分布式存储来说，须要存储提供一些专用的配置信息，提供对立的集群视图。存储具备读写速度快，反对高可用且部署简略。此时，就须要应用到 etcd 了。
分布式存储节点角色个别有：mgr，mds 和 oss。其中 mgr 是集群的治理节点，提供共享配置和保护集群主从视图，mds 存储集群的元数据，oss 则用来存储用户数据。
将 etcd 纳入分布式存储外部的架构图如下所示：
利用 etcd lease 机制为分布式存储选主
etcd lease 机制可能确保一个 etcd 集群中的 key 领有一种临时性的特色，被指定某个 lease 的 key 只能在集群中存活某一段时间，工夫到了就会被集群主动删除。这段存活工夫叫做 TTL (Time To Live)。
mgr 节点之间能够竞争 etcd 中同一个领有 lease 属性的 key，比方:“/dfs/mgr/master”。当一个 mgr 节点竞争到这个 key，他就成为了 mgr 主，同时其余节点就成为了 mgr 从。mgr 节点存活期间，定期给本人的 lease 续租，就能够始终放弃本人的 mgr 主身份。一旦 mgr 主产生异样（比方宕机），过了 TTL 工夫后，其持有的 key 就会被主动删除。此时，mgr 从节点发现“/dfs/mgr/master”key 不存在后，就会从新竞争 mgr 主，从新取得此 key 的 mgr 降级为新的 mgr 主。
利用 etcd watch 机制为组件探活
etcd 提供了 watch 机制，客户端 watch 了一系列 key，当这些被 watch 的 key 数据发生变化时，就会产生相应的事件告诉客户端，相干的事件类型有：set, delete, update, create, compareAndSwap, compareAndDelete。
在 mds 服务启动时，向 etcd 注册本人的 ip（例如 /dfs/mds_nodes/, /dfs/mds_nodes/…），该 key 领有 lease 属性。一旦 mds 服务异样，该 mds 的 ip 就会从 etcd 中 /dfs/mds_nodes 主动删除。这样，咱们在 mgr 主节点启动监听 /dfs/mds_nodes 目录，就会失去某个 mds 上线和下线的事件告诉，并且能够对 mds 相应的状态做标记，如果是 mds 主下线，则立刻执行 mds 主从切换。
oss 同 mds 一样，监听的的目录变为 /dfs/oss_nodes。
通过 etcd 的 watch 机制，咱们能疾速地感知到 mds 或 oss 故障，进行 mds 或 oss 的主从切换（工夫管制在 10 秒以内），从而保障客户端业务不受影响。
利用 etcd 做配置共享
etcd 高可用个性和疾速读写，为咱们应用配置共享提供了根底。咱们把 mgr，mds，oss 的配置信息写入 etcd 集群中，各个组件从 etcd 集群中读取相应配置即可。
etcd 集群节点个数和性能
据 etcd 官网介绍，etcd V3 版本最高能够提供每秒 1 万次写入操作。然而随着 etcd 节点个数的减少，其写入性能会逐步升高，所以咱们个别采纳 3 节点，5 节点或 7 节点部署 etcd 集群。大家可能会问：为什么不采纳偶数节点，比方 4 节点，6 节点呢？因为 etcd 采纳 Raft 协定，是 quorum 机制，要求半数以上节点在线。所以 4 节点的容错性和 3 节点是等价的，都是只能容许一个节点故障。然而多一个节点，一方面写入性能不如 3 节点，另一方面偶数节点在 etcd 外部选主时，有可能造成某一轮两个 candidate 节点获取的选票统一，从而缩短选主工夫。
etcd 反对 IPv6 协定
对于某些用户，为了平安，不提供 IPv4 地址，主机只有 IPv6 地址。这时候，etcd 的 IPv6 就发挥作用了。咱们用实例展现，etcd 如何配置 IPv6 进行节点间通信，如下图所示（etcd 单节点集群）:
该实例的 IPv6 地址为 2022::24，应用时，用 [] 将 IPv6 地址括起来即可。须要留神的是该 IPv6 地址只能应用 Scope global 类型，不能应用 Scope link 类型，否则，在启动 etcd 服务时，会报 bind 地址有效谬误。
据统计，目前至多有 CoreOS、Kubernetes、Cloud Foundry，以及在 Github 上超过 500 个我的项目在应用 etcd。
