Consul KV Store 有哪些应用场景？怎么用才不踩坑

Consul KV Store 是 Consul 内置的分布式键值存储，基于 Raft 协议保证强一致性，主要用在四个场景：动态配置管理——应用启动时从 KV 读取配置，配合 Watch 机制实现配置热更新，不用重启服务；分布式锁——通过 session + acquire/release 实现互斥访问，锁会随 session 过期自动释放，避免死锁；领导选举——多个实例抢同一个 key 的 acquire，拿到的就是 leader，session 断开自动重新选举；特性开关——用布尔值 key 控制功能灰度上线，比改代码上线快得多。

单个 key 的 value 上限 512KB，所以 KV Store 不是数据库，别往里塞大块数据，否则会拖慢 Raft 日志复制，影响服务发现和健康检查的核心功能。

读写走 HTTP API：PUT /v1/kv/{key} 写入，GET /v1/kv/{key}?raw 读取纯文本，DELETE /v1/kv/{key} 删除。CAS 操作加 ?cas={ModifyIndex} 参数，只有版本匹配才写入成功，并发场景下防止覆盖别人的更新。

追问

Consul KV 和 etcd 有什么区别？

对比项	Consul KV	etcd
定位	服务发现附带功能	专用 KV 存储
值大小限制	512KB	1.5MB
事务	支持（PUT /v1/txn）	支持（Txn API）
多数据中心	原生支持	需额外工具

选型逻辑：如果已经在用 Consul 做服务发现，KV 直接用就行，不用再引入 etcd；如果只需要一个专用 KV 存储且数据量较大，etcd 更合适。

分布式锁用 KV 怎么实现？踩过什么坑？

创建 session → kv put -acquire -session={sessionId} lock/key 获取锁，用完 kv put -release 释放。关键点是 session 必须设置 TTL 且要定期 renew，否则 session 过期锁自动释放，其他实例拿锁后你的业务可能还在跑——就出并发问题了。另外锁粒度别太细，大量细粒度锁会增加 Raft 日志压力。

实际项目里怎么监听配置变更？

用 consul watch -type=key -key=config/app/name handler.sh，或者用 Consul Template 配合 Go 模板语法，key 变化时自动重新生成配置文件并触发服务 reload。坑是 Watch 回调如果执行太慢会堆积事件，handler 里面别做耗时操作。

数据怎么跨数据中心同步？

KV 数据不会自动跨 DC 复制。需要用 consul-replicate 工具单向同步，或者自己写逻辑通过 HTTP API 跨 DC 读写。跨 DC 场景下要注意网络延迟对 Raft 写入性能的影响。