etcd 学习系列（一）：从业务需求出发，理解 etcd 是什么

前言

最近因为工作需要，接触到了一个 etcd 集群迁移的项目。在此之前，我对 etcd 的了解仅限于"它是 K8s 的存储后端"。但真正上手之后，才发现 etcd 远比我想象的要有趣------它不仅仅是一个数据库，更是分布式系统的基石。

这篇文章记录了我从零开始学习 etcd 的过程，希望能帮助到同样对 etcd 感兴趣的读者。

一个场景：配置管理需要版本控制

假设你有一个微服务应用，它的配置（数据库连接、超时时间、功能开关等）需要经常修改。传统的做法是：

SSH 到服务器
修改配置文件
重启应用

这样做的问题很明显：需要重启，有停机时间，而且没有版本控制 。K8s 的 ConfigMap 解决了热加载的问题（Pod 挂载的文件会自动更新），但不支持版本控制------每次修改直接覆盖，旧值就丢了，无法回滚。

那么，能不能有一个"配置中心"，既支持热加载，又支持版本控制？

这就是 etcd 登场的地方。

etcd 是什么？

etcd 是一个分布式的 key-value 存储系统。这句话里有两个关键词：

1. key-value 存储

etcd 存储数据的方式非常简单------key 像文件路径，value 是文件内容。

复制代码

key   = /default/myapp/prod/config/db_url/1700123456
value = "jdbc:mysql://db.example.com:3306/mydb"

/                          ← 根目录
├── default/               ← 分组/命名空间
│   ├── myapp/             ← 应用名
│   │   ├── prod/          ← 环境（生产/测试）
│   │   │   └── config/    ← 配置类型
│   │   │       ├── db_url/1700123456 → "jdbc:mysql://..."
│   │   │       └── timeout/1700123457 → "30"

2. 分布式

etcd 不是单机运行的，通常由 3 台或 5 台机器组成一个集群。数据在集群中自动同步，挂掉 1 台机器，服务仍然可用。

为什么 etcd 适合做配置中心？

etcd 有三个特性，让它成为配置中心的理想选择：

特性一：Watch 机制（配置热加载的核心）

传统方式：应用每隔 30 秒轮询一次配置 → 效率低，实时性差 ✅

复制代码

应用 → 每隔 30 秒读一次 etcd → 没变化 → 等 30 秒 → 再读...

etcd 的 watch 方式：应用告诉 etcd "我盯着这个 key"，有变化了 etcd 主动推送 ✅

复制代码

应用 → watch /default/myapp/prod/config/ → 保持连接
etcd → 配置变了 → 推送给应用 → 应用热加载

不需要重启，不需要轮询，配置变更秒级生效。

特性二：高可用

复制代码

3 节点 etcd 集群：
  - 挂 1 台，还能正常工作
  - 挂 2 台，只读不可写（但极少发生）
  - 数据自动同步，一致性有保障

特性三：版本控制（需要应用层配合）

这里要特别说明：etcd 本身不提供业务层面的版本控制。etcd 只存 key-value，版本控制是"配置中心"在 etcd 之上自己实现的逻辑。

常见的做法是：

每次修改配置，不覆盖旧 key，而是创建新 key
key 的路径中包含版本号（如时间戳）
应用读取版本号最大的那个作为最新配置

/.../db_url/1700123456 → "旧地址" ← 历史版本
/.../db_url/1700123457 → "新地址" ← 当前版本

如果需要回滚，把"最新版本"指向旧版本号即可。

对比：K8s ConfigMap vs 独立 etcd 配置中心

对比项	K8s ConfigMap	独立 etcd 配置中心
热加载	✅ 文件自动更新	✅ Watch 推送
版本控制	❌ 直接覆盖	✅ 应用层实现
回滚	❌ 需要手动恢复	✅ 选择历史版本即可
操作审计	❌ 无日志	✅ 记录谁改了、什么时候改的

小结

etcd 本质上就是一个分布式的 key-value 数据库。它之所以能成为配置中心的首选，不是因为它有什么特殊功能，而是因为：

Watch 机制：让配置变更能实时推送到应用，实现热加载
高可用：3 节点集群，挂 1 台不影响服务
简单可靠：key-value 模型，容易理解和使用

而版本控制，是配置中心在 etcd 之上自己实现的，不是 etcd 自带的功能。

下一篇文章，我们来聊聊 etcd 的集群架构------3 台机器之间是怎么分工合作的，以及 2379 和 2380 这两个端口到底有什么区别。

下一篇：[etcd 学习系列（二）：集群架构 ------ 3 节点是如何工作的](#etcd 学习系列（二）：集群架构 —— 3 节点是如何工作的)