键值存储分几类
键值类系统按定位可以分成三档：缓存型（Redis、Memcached）面向高频读写且可容忍丢失；协调型（etcd、Consul）面向数据量小但绝不能错、还需要变更通知的场景；托管型用容量与延迟规格换取免运维。选型的关键不是比较功能清单，而是先回答两个问题：这份数据丢了会怎样、需要多强的读写一致性。
定位对照
| 系统 | 关键能力 | 不适合的场景 |
|---|---|---|
| Redis | 亚毫秒读写、多种数据结构、复制与集群 | 需要 SQL 与复杂二级索引的业务数据 |
| Memcached | 简单 KV、多线程、纯缓存 | 持久化、复制、复杂数据结构 |
| etcd | Raft 强一致、watch 变更通知、租约 | 高频大数据量读写（写吞吐有限） |
| 托管 KV 服务 | 弹性容量、按量计费、免运维 | 需要自控内核与深度定制的场景 |
基本信息
| 数据模型 | 键到值的映射，值可以是简单字符串或复杂结构（视产品而定） |
|---|---|
| 一致性 | 从最终一致到强一致都有，Raft 类协调服务为强一致 |
| 持久化 | 缓存型多为可选持久化，协调型把持久化作为默认前提 |
| 容量口径 | 内存型受内存上限约束，调大上限与淘汰策略要一起考虑 |
| 变更通知 | watch 与订阅能力是协调型系统的核心差异点 |
典型使用场景
- 会话与登录态：允许丢失、可重建，缓存型最合适
- 热点数据缓存：抗住读放大，注意缓存与数据库的一致性策略
- 分布式锁与选主：需要强一致与租约，用协调型而非缓存型
- 配置与开关下发：少量关键数据加 watch 通知，改动要实时生效
- 计数与限流：单键原子操作简单高效，但要注意热点键的倾斜问题
etcd 典型用途
etcd 典型用途
# 少量关键数据 + 变更通知：配置与开关的典型用法
etcdctl put /config/app/max_conn 200
etcdctl get /config/app/max_conn
etcdctl watch /config/app/ --prefix # 变更实时推送给订阅方
# 租约：绑定 TTL 的键，用于心跳与故障判定
# etcdctl lease grant 30
# etcdctl put /nodes/worker-1 alive --lease=<lease-id>判断口诀：数据量大且可丢选缓存型；数据量小、不能错且需要变更通知选协调型；预算换运维选托管型。
把配置数据与业务缓存放在同一个缓存实例里风险很高：淘汰策略会把配置逐出，导致依赖配置的服务突然读不到参数。