etcd笔记（01）—etcd简介、特点、应用场景、常用术语、分布式CAP理论、分布式原理

1. etcd 简介

etcd 官网定义&＃xff1a;

A highly-available key value store for shared configuration and service discovery.

即一个用于配置共享和服务发现的键值存储系统。

etcd 是一款分布式存储中间件&＃xff0c;使用 Go 语言编写&＃xff0c;并通过 Raft 一致性算法处理和确保分布式一致性&＃xff0c;解决了分布式系统中数据一致性的问题。

而且作为一款分布式、可靠的键值存储组件&＃xff0c;etcd 常用于微服务架构中的服务注册与发现中心&＃xff0c;相较于 ZooKeeper 部署更简单&＃xff0c;而且具有数据持久化、支持 SSL 客户端安全认证的独特优势。

etcd 作为一个可信赖的分布式键值存储服务&＃xff0c;它能够为整个分布式集群存储一些关键数据&＃xff0c;协助分布式集群的正常运转。

etcd 可集中管理配置信息。服务端将配置信息存储于 etcd&＃xff0c;客户端通过 etcd 得到服务配置信息&＃xff0c;etcd 监听配置信息的改变&＃xff0c;发现改变通知客户端。

而 etcd 满足 CAP 理论中的 CP&＃xff08;一致性和分区容错性&＃xff09; 指标&＃xff0c;由此我们知道&＃xff0c;etcd 解决了分布式系统中一致性存储的问题。

2. etcd 特点

etcd 可以用来构建高可用的分布式键值数据库&＃xff0c;总结来说有如下特点。

• 简单&＃xff1a;安装简单&＃xff0c;且为用户提供了 HTTP API&＃xff0c;使用起来也很简单&＃xff1b;
• 存储&＃xff1a;数据分层存储在文件目录中&＃xff0c;类似于我们日常使用的文件系统&＃xff1b;
• Watch 机制&＃xff1a;Watch 指定的键、前缀目录的更改&＃xff0c;并对更改时间进行通知&＃xff1b;
• 安全通信&＃xff1a;支持 SSL 证书验证&＃xff1b;
• 高性能&＃xff1a;etcd 单实例可以支持 2K/s 读操作&＃xff0c;官方也有提供基准测试脚本&＃xff1b;
• 一致可靠&＃xff1a;基于 Raft 共识算法&＃xff0c;实现分布式系统内部数据存储、服务调用的一致性和高可用性&＃xff1b;
• Revision 机制&＃xff1a;每个 Key 带有一个 Revision 号&＃xff0c;每进行一次事务便加一&＃xff0c;因此它是全局唯一的&＃xff0c;如初始值为 0&＃xff0c;进行一次 Put 操作&＃xff0c;Key 的 Revision 变为 1&＃xff0c;同样的操作&＃xff0c;再进行一次&＃xff0c;Revision 变为 2&＃xff1b;换成 Key1 进行 Put 操作&＃xff0c;Revision 将变为 3。这种机制有一个作用&＃xff0c;即通过 Revision 的大小就可知道写操作的顺序&＃xff0c;这对于实现公平锁&＃xff0c;队列十分有益&＃xff1b;
• Lease 机制&＃xff1a;即租约机制&＃xff08;TTL&＃xff0c;Time To Live&＃xff09;&＃xff0c;Etcd 可以为存储的 Key-Value 对设置租约&＃xff0c;当租约到期&＃xff0c;Key-Value 将失效删除&＃xff1b;同时也支持续约&＃xff0c;通过客户端可以在租约到期之前续约&＃xff0c;以避免 Key-Value 对过期失效&＃xff1b;此外&＃xff0c;还支持解约&＃xff0c;一旦解约&＃xff0c;与该租约绑定的 Key-Value 将失效删除&＃xff1b;

etcd 是一个实现了分布式一致性键值对存储的中间件&＃xff0c;支持跨平台&＃xff0c;etcd 集群中的节点基于 Raft 算法进行通信&＃xff0c;Raft 算法保证了微服务实例或机器集群所访问的数据的可靠一致性。

在分布式系统或者 Kubernetes 集群中&＃xff0c;etcd 可以作为服务注册与发现和键值对存储组件。

3. 应用场景

etcd 在稳定性、可靠性和可伸缩性上表现极佳&＃xff0c;同时也为云原生应用系统提供了协调机制。etcd 经常用于服务注册与发现的场景&＃xff0c;此外还有键值对存储、消息发布与订阅、分布式锁等场景。

3.1 键值对存储

etcd 是一个用于键值存储的组件&＃xff0c;存储是 etcd 最基本的功能&＃xff0c;其他应用场景都建立在 etcd 的可靠存储上。比如 Kubernetes 将一些元数据存储在 etcd 中&＃xff0c;将存储状态数据的复杂工作交给 etcd&＃xff0c;Kubernetes 自身的功能和架构就能更加稳定。

3.2 服务注册与发现

etcd 基于 Raft 算法&＃xff0c;能够有力地保证分布式场景中的一致性。各个服务启动时注册到 etcd 上&＃xff0c;同时为这些服务配置键的 TTL 时间。注册到 etcd 上面的各个服务实例通过心跳的方式定期续租&＃xff0c;实现服务实例的状态监控。

3.3 消息发布与订阅

在分布式系统中&＃xff0c;服务之间还可以通过消息通信&＃xff0c;即消息的发布与订阅&＃xff0c;如下图所示&＃xff1a;

通过构建 etcd 消息中间件&＃xff0c;服务提供者发布对应主题的消息&＃xff0c;消费者则订阅他们关心的主题&＃xff0c;一旦对应的主题有消息发布&＃xff0c;就会产生订阅事件&＃xff0c;消息中间件就会通知该主题所有的订阅者。

3.4 分布式锁

分布式系统中涉及多个服务实例&＃xff0c;存在跨进程之间资源调用&＃xff0c;对于资源的协调分配&＃xff0c;单体架构中的锁已经无法满足需要&＃xff0c;需要引入分布式锁的概念。etcd 基于 Raft 算法&＃xff0c;实现分布式集群的一致性&＃xff0c;存储到 etcd 集群中的值必然是全局一致的&＃xff0c;因此基于 etcd 很容易实现分布式锁。

4. etcd 的核心架构

从上图可知&＃xff0c;etcd 有 etcd Server、gRPC Server、存储相关的 MVCC 、Snapshot、WAL&＃xff0c;以及 Raft 模块。

其中&＃xff1a;

• etcd Server 用于对外接收和处理客户端的请求&＃xff1b;
• gRPC Server 则是 etcd 与其他 etcd 节点之间的通信和信息同步&＃xff1b;
• MVCC 即多版本控制&＃xff0c;etcd 的存储模块&＃xff0c;键值对的每一次操作行为都会被记录存储&＃xff0c;这些数据底层存储在 BoltDB 数据库中&＃xff1b;
• WAL 预写式日志&＃xff0c;etcd 中的数据提交前都会记录到日志&＃xff1b;
• Snapshot 快照&＃xff0c;以防 WAL 日志过多&＃xff0c;用于存储某一时刻 etcd 的所有数据&＃xff1b;
• Snapshot 和 WAL 相结合&＃xff0c;etcd 可以有效地进行数据存储和节点故障恢复等操作&＃xff1b;

虽然 etcd 内部实现机制复杂&＃xff0c;但对外提供了简单的 API 接口&＃xff0c;方便客户端调用。我们可以通过 etcdctl 客户端命令行操作和访问 etcd 中的数据&＃xff0c;或者通过HTTP API 接口直接访问 etcd。

etcd 中的数据结构很简单&＃xff0c;它的数据存储其实就是键值对的有序映射。etcd 还提供了一种键值对监测机制&＃xff0c;即 Watch 机制&＃xff0c;客户端通过订阅相关的键值对&＃xff0c;获取其更改的事件信息。Watch 机制实时获取 etcd 中的增量数据更新&＃xff0c;使数据与 etcd 同步。

etcd 目前有 V2.x 和 V3.x 两个大版本。etcd V2 和 V3 是在底层使用同一套 Raft 算法的两个独立应用&＃xff0c;但相互之间实现原理和使用方法上差别很大&＃xff0c;接口不一样、存储不一样&＃xff0c;两个版本的数据互相隔离。

至于由 etcd V2 升级到 etcd V3 的情况&＃xff0c;原有数据只能通过 etcd V2 接口访问&＃xff0c;V3 接口创建的数据只能通过新的 V3 的接口访问。

etcd 架构图&＃xff1a;
通常&＃xff0c;etcd 会监听两个端口&＃xff0c;默认是 2379 端口和 2380 端口。其中&＃xff0c;2380 端口用于集群内部通信&＃xff0c;主要涉及集群间数据同步、心跳、选举等。2379 端口用于与客户端通信&＃xff0c;比如接收客户端发起的读/写数据请求。

etcd 节点在部署的时候有两种运行模式&＃xff1a;集群模式和代理模式。

当 etcd 节点以集群模式运行时&＃xff0c;它会加入已有集群中&＃xff0c;作为集群的一部分。也就是说&＃xff0c;后续的心跳、数据同步、选举等它都会参与。

集群模式中的节点数一般采用奇数个。为什么呢&＃xff1f;因为假如同时有两个 Candidate 发起选举&＃xff0c;如果是偶数节点的话&＃xff0c;可能存在两个 Candidate 获得相同票数。

这会导致什么问题&＃xff1f;如果两个 Candidate 票数一样&＃xff0c;就需要再次发起选举&＃xff0c;而再次发起选举还是有一定概率出现票数一样&＃xff0c;这会导致选举耗时较多&＃xff0c;影响稳定性。所以&＃xff0c;采用奇数个节点&＃xff0c;能有效降低票数一样的概率&＃xff0c;提升选举的效率。另外&＃xff0c;使用奇数节点来部署&＃xff0c;也能让 etcd 很好地处理分区容错问题。

当某个 etcd 节点以代理模式运行时&＃xff0c;该节点负责将接收到的请求转发给 etcd 集群节点。目前 etcd 接口有 v2 和 v3 两个版本&＃xff0c;其中 v2 是 HTTP 接口&＃xff0c;v3 是 gRPC 接口。需要注意的是&＃xff0c;代理模式只支持转发 v2 版本的请求&＃xff0c;也就是只支持转发 HTTP 请求。

不过&＃xff0c;由于 etcd v3 接口在性能、安全、稳定性等方面要比 v2 接口优秀很多&＃xff0c;新项目倾向于使用 v3 接口&＃xff0c;老项目也逐渐从 v2 接口迁移到 v3 接口。也就是说&＃xff0c;代理模式以后可能逐渐被淘汰掉。

5. 分布式中的 CAP 理论

CAP 原理是描述分布式系统下节点数据同步的基本定理&＃xff0c;分别指

• Consistency&＃xff08;一致性&＃xff09;

指数据一致性&＃xff0c;表示一个系统的数据信息&＃xff08;包括备份数据&＃xff09;在同一时刻都是一致的。在分布式系统下&＃xff0c;同一份数据可能存在于多个不同的实例中&＃xff0c;在数据强一致性的要求下&＃xff0c;修改其中一份数据后必须同步到它的所有备份中。在数据同步的任何时候&＃xff0c;都需要保证所有对该份数据的请求将返回同样的状态。

• Availability&＃xff08;可用性&＃xff09;

指服务可用性&＃xff0c;要求服务在接收到客户端请求后&＃xff0c;都能够给出响应。服务可用性考量的是系统的可用性&＃xff0c;要求系统在高并发情况和部分节点宕机的情况下&＃xff0c;系统整体依然能够响应客户端的请求。

• Partition tolerance&＃xff08;分区容错性&＃xff09;

指分区容忍性。在分布式系统中&＃xff0c;不同节点之间通过网络进行通信。由于网络的不可靠性&＃xff0c;位于不同网络分区的服务节点可能会通信失败&＃xff0c;如果系统能够容忍这种情况&＃xff0c;说明它是满足分区容忍性的。如果系统不能满足&＃xff0c;将会限制分布式系统的扩展性&＃xff0c;即服务节点的部署数量和地区都会受限&＃xff0c;也就违背了分布式系统设计的初衷&＃xff0c;所以一般来说分布式系统都会满足分区容忍性。

这三个要素最多只能同时实现两点&＃xff0c;不能三者兼顾。

基于分布式系统的基本特质&＃xff0c;P&＃xff08;分区容错性&＃xff09;是必须要满足的&＃xff0c;所以接下来需要考虑满足 C&＃xff08;一致性&＃xff09;还是 A&＃xff08;可用性&＃xff09;。

但是在满足了分区容忍性的前提下&＃xff0c;分布式系统并不能同时满足数据一致性和服务可用性。

假设服务 A 现在有两个实例 A1 和 A2&＃xff0c;它们之间的网络通信出现了异常&＃xff0c;基于分区容忍性&＃xff0c;这并不会影响 A1 和 A2 独立的正常运行。假如此时客户端请求 A1&＃xff0c;请求将数据 B 从 B1 状态修改为 B2&＃xff0c;由于网络的不可用&＃xff0c;数据 B 的修改并不能通知到实例 A2。

如果此时另一个客户端向 A2 请求数据 B&＃xff0c;如果 A2 返回数据 B1&＃xff0c;将满足服务可用性&＃xff0c;但并不能满足数据一致性&＃xff1b;如果A2 等待 A1 的通知后才返回数据 B 的正确状态&＃xff0c;虽然满足了数据一致性&＃xff0c;但并不能响应客户端请求&＃xff0c;违背了服务可用性的指标。

在类似银行之类对金额数据要求强一致性的系统中&＃xff0c;要优先考虑满足数据一致性&＃xff1b;而在大众网页之类的系统中&＃xff0c;用户对网页版本的新旧不会有特别的要求&＃xff0c;在这种场景下服务可用性会高于数据一致性。

6. 常用术语

7. 分布式原理

7.1 客户端

当 RPC 服务部署在多个节点上时&＃xff0c;客户端得到的是一个服务列表&＃xff0c;有多个 IP 端口对。客户端的连接池可以随机地挑选任意的 RPC 服务节点进行连接。

每个服务节点应该有个权重值&＃xff0c;当所有节点的权重值一样时&＃xff0c;它们的流量分配就是均匀的。如果某个节点的相对权重值较小&＃xff0c;它被客户端选中的概率也会相对比较小。

class RPCNode {String addr; // 服务地址int weight; // 节点权重
}class RPCCluster {RPCNode[] nodes; // 节点列表Node random(); // 按权重随机挑选节点
}


7.2 容灾

当有一个服务节点挂掉时&＃xff0c;客户端需要采取一定的策略避免请求失败。当请求失败时&＃xff0c;客户端还要进行重试&＃xff0c;但是也不可以无限重试&＃xff0c;要有一定的重试策略。

比如当节点挂掉时&＃xff0c;将失效节点摘除&＃xff0c;放置到失效节点列表中。然后每隔一段时间检查失效节点是否恢复了&＃xff0c;如果恢复了&＃xff0c;那就从失效节点中移除&＃xff0c;再将节点地址重新加入到有效节点列表中。那如何判断节点真的挂掉了呢&＃xff0c;一般需要设置一个时间窗口&＃xff0c;统计在一定时间窗口里出现的错误数量。如果这个数量过大&＃xff0c;那就意味着失效了。这也是为了防止网络偶然抖动导致服务节点流量的大幅波动。

7.3 降权法

上面提到客户端会为每个节点赋予一个权值&＃xff0c;改变权值就可以改变节点的相对流量。如果某个节点出现了一次调用错误&＃xff0c;可以对该节点进行降权。如果错误次数过多&＃xff0c;降权会降的很快&＃xff0c;最终达到一个最小值。之所以不应该降到零&＃xff0c;那是为了给节点提供一个恢复的机会。被降权的节点后来只要有一次调用成功&＃xff0c;那么 weight 值就应该尽快被还原&＃xff0c;这样节点就可以快速恢复为正常节点。

客户端一次调用失败会尝试重试。如果降权太慢&＃xff0c;会导致重试次数太多&＃xff0c;因为第二次随机挑选节点时还是很有可能再次挑选到失效节点。降权太快也不好&＃xff0c;网络抖动会导致节点流量分配的快速抖动&＃xff0c;瞬间从正常降到近零&＃xff0c;又可以瞬间从近零恢复到正常。

一个简单的策略是权重减半法。错误一次权重减半&＃xff0c;连续错误两次权重就降到 1/4&＃xff0c;如此直到降到最小值。如果初始权重值是 1024&＃xff0c;那么权重值就会逐渐衰减1024&＃61;>512&＃61;>256&＃61;>128&＃61;>64&＃61;>32&＃61;>16&＃61;>8&＃61;>4&＃61;>2&＃61;>1。如果节点恢复了&＃xff0c;那么调用会成功&＃xff0c;权重就可以直接恢复到正常值&＃xff0c;也可以通过加倍法逐渐恢复到正常值1&＃61;>2&＃61;>4&＃61;>8&＃61;>16&＃61;>32&＃61;>64&＃61;>128&＃61;>256&＃61;>512&＃61;>1024。如果希望恢复的更快一点&＃xff0c;可以通过乘 4 法&＃xff0c;乘 8 法。

7.4 服务发现

健壮的服务应该是可以支持动态扩容的服务。比如 RPC 服务压力过大&＃xff0c;希望通过增加节点的方式来减小单个 RPC 服务的压力。如果使用的是前面的静态 RPC 服务地址列表&＃xff0c;那么当节点增加时&＃xff0c;我们需要修改客户端的配置重启才能生效。

通过服务发现技术&＃xff0c;当 RPC 服务节点增加或减少时&＃xff0c;客户端可以动态快速收到服务列表的变更信息&＃xff0c;从而可以实时调整连接配置&＃xff0c;这样无需重启就可以完成服务的扩容和缩容。

class ServiceDiscovery(object):def register_service(self, name, addr):passdef get_services(self, name):passdef on_services_changed(self, name):pass


服务发现技术依赖于服务之间的特殊中间节点。这个节点的作用就是接受服务的注册&＃xff0c;提供服务的查找&＃xff0c;以及服务列表变更的实时通知功能。它一般使用支持高可用的分布式配置数据库作为解决方案&＃xff0c;如 zookeeper/etcd 等。

• 服务注册——服务节点在启动时将自己的服务地址注册到中间节点
• 服务查找——客户端启动时去中间节点查询服务地址列表
• 服务变更通知——客户端在中间节点上订阅依赖服务列表的变更事件。当依赖的服务列表变更时&＃xff0c;中间节点负责将变更信息实时通知给客户端。