etcd 3.7 评测：分布式系统的关键状态存储，Raft 共识与运维成本
etcd 是为分布式系统最关键数据设计的分布式可靠键值存储，采用 Raft 共识算法，提供自动 TLS 和 gRPC API。
秒懂
- 它是什么？
- etcd 是一个用 Go 编写的分布式可靠键值存储，面向分布式系统中最关键的数据。本文基于官方文档与仓库信息，分析其 Raft 共识机制、部署方式、适用场景与局限性。
- 适合谁用？
- 如果你的系统需要为 Kubernetes、服务发现或分布式锁提供强一致性的元数据存储，etcd 是经过生产验证的选择，尤其是 3.5 及之后的版本。但如果你只需要简单的缓存或非关键数据存储，etcd 的运维复杂度（集群管理、备份、故障恢复）可能超出收益。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Go（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题：分布式系统的关键状态存储
etcd 定位很明确：存储分布式系统中最关键的数据。这类数据包括配置信息、服务发现记录、分布式锁的元数据，以及 Kubernetes 集群的状态。它不是一个通用数据库，而是为强一致性和高可用而设计的键值存储。它的目标用户是构建分布式系统的工程师，尤其是那些需要处理选举、领导者变更和网络分区问题的团队。etcd 通过 Raft 共识算法来保证多个节点之间的数据一致，即使部分节点故障，只要多数派存活，集群就能继续工作。
Raft 共识与数据流：写入如何达成一致
etcd 使用 Raft 共识算法来管理一个高可用的复制日志。写入请求首先到达领导者节点，领导者将操作追加到日志中，然后复制给其他节点。当多数派节点确认写入后，该操作才会被提交并应用到状态机。这个过程保证了线性一致性，但也意味着每次写入都需要网络往返和磁盘同步。etcd 的 API 基于 gRPC，定义了清晰的客户端接口。官方强调其可靠性通过严格的鲁棒性测试来保证，仓库中有一个专门的 robustness 测试目录，用于模拟各种故障场景。这种设计是有代价的：写入延迟受网络和磁盘性能影响，吞吐量有上限。
启动一个单节点集群：两条命令
从 release 页面下载预编译二进制，然后直接运行 etcd 命令即可启动单节点集群。默认监听 2379 端口用于客户端通信，2380 端口用于节点间通信。使用 etcdctl 可以写入和读取键值：etcdctl put mykey "this is awesome"，然后 etcdctl get mykey。要启动一个本地多节点集群，可以安装 goreman 工具，然后运行 goreman start，它会根据 Procfile 文件启动三个成员 infra1、infra2 和 infra3，以及一个可选的 grpc-proxy。这个流程适合本地开发测试，但生产环境需要手动配置集群成员和 TLS。
配置与安全：TLS 是默认要求吗
etcd 支持自动 TLS 以及可选的客户端证书认证，这意味着你可以配置双向 TLS 来加密通信。官方文档明确指出，生产环境应该使用 TLS 来保护集群。但默认情况下，etcd 以明文模式运行，这适合本地测试。配置密钥包括 --cert-file、--key-file 和 --client-cert-auth 等，具体参数在官方配置指南中有详细说明。安全配置需要额外的工作，但这是运行关键数据存储的必要步骤。
性能与限制：1 万次写入每秒的代价
官方宣称 etcd 的性能为每秒 1 万次写入。这个数字是基准测试结果，实际性能取决于硬件、网络和磁盘类型。Raft 共识要求每次写入都要同步到多数派节点，因此写入延迟至少是一个网络往返加上磁盘 fsync 的时间。如果你的应用需要高吞吐写入，etcd 不是合适的选择。此外，etcd 不适合存储大量数据，它的设计目标是存储关键元数据，而不是海量数据。当数据量增长时，快照和压缩操作会增加 CPU 和 I/O 开销。
维护与升级：版本分支与稳定性
etcd 的 main 分支可能处于不稳定甚至损坏的状态，官方明确建议使用 release 版本。当前有三个活跃的发布分支：v3.7、v3.6 和 v3.5。v3.5 系列持续更新，例如 v3.5.33，表明长期维护的承诺。升级需要谨慎，因为 etcd 的存储格式和 API 可能在不同主版本间发生变化。在升级前，务必阅读官方升级指南并备份数据。此外，etcd 使用 Apache-2.0 许可证，允许商业使用，但需要保留版权声明。
替代方案：什么情况下不要用 etcd
对于非关键数据或需要更高吞吐的键值存储，可以考虑其他方案。例如，Redis 提供更低的延迟和更高的吞吐，但不提供强一致性和自动故障转移。ZooKeeper 是另一个使用 ZAB 协议的一致性协调服务，但它的 API 更底层，且运维复杂度类似。etcd 的优势在于与 Kubernetes 的深度集成，以及 gRPC API 的简洁性。如果你的系统已经使用 Kubernetes，etcd 几乎是必然选择。但如果你的系统是独立的微服务架构，且不需要强一致性的协调功能，那么使用一个简单的键值存储可能更省心。
编辑结论
如果你的系统需要为 Kubernetes、服务发现或分布式锁提供强一致性的元数据存储，etcd 是经过生产验证的选择，尤其是 3.5 及之后的版本。但如果你只需要简单的缓存或非关键数据存储，etcd 的运维复杂度（集群管理、备份、故障恢复）可能超出收益。建议先验证你的故障容忍需求：单节点部署无法提供高可用，多节点集群需要奇数成员并配置合理的选举超时。同时，评估你的写入频率，etcd 的 Raft 日志复制会限制吞吐，官方基准为每秒 1 万次写入，不适合高吞吐的日志或消息队列场景。在采用前，务必阅读官方文档中的配置与调优指南，并测试备份恢复流程。
社区笔记