一杯咖啡的时间，聊聊技术与成长
ZK 还是 etcd：云原生时代的协调服务选型
协议层面 ZAB 与 Raft 半斤八两，选型的天平其实压在时代与生态上：老栈躲不开 ZK，新栈顺手用 etcd，跑在 K8s 上的团队更是零成本白得一个 Raft 集群。本篇算清功能、运维、托管三本账。
fencing token：当持有人是个幽灵，下游凭什么拒绝它
锁的知情机制只能降低幽灵概率，挡不住冻结复活的客户端继续写入。真正的防线在下游：锁服务发单调递增令牌，存储只认见过的最大令牌——旧持有者的写入，无论它怎么自证清白，一条都进不来。
不用锁行不行：四个替代方案的正确打开方式
想加锁之前先停三秒：互斥的对象是数据还是逻辑？如果只是一行数据，版本号、唯一索引、行锁、队列串行化四个替代方案，个个比分布式锁便宜可靠。很多「抢锁」的冲动，其实是设计可以绕开的信号。
三种锁横向对比：一张选型地图
Redis 十万级 QPS 但共识缺位，ZK 共识过硬但千级吞吐，etcd 两头占优但要看生态脸色。选型不是比参数，是比场景：高频竞争给 Redis，低频高危给 ZK/etcd，强一致资金叠 fencing。多数团队的最优解出人意料地朴素。
etcd 分布式锁：一个 Lease 管生死，一个 Revision 排公平
etcd 造锁只用了两块积木：Lease 租约绑住 key 的生死，keepalive 续命——进程崩了锁自动蒸发；创建 revision 全局单调——排队公平白送。对照 ZK 临时顺序节点概念一一对应，但流式 Watch 让实现简洁了一个量级。
Raft 深入：两条提交红线与一份不可能丢的日志
过半 ACK 就提交？没那么简单。旧任期的日志哪怕复制到五台也不能直接提交，否则会丢已提交数据——Raft 用「只提交当前任期」的红线堵死它。本篇把安全性抠到细节：日志新旧的精确判定、读请求的线性一致、脑裂为何数学上不成立。
etcd 基础与 Raft 入门：一票、一任期、一份日志
Kubernetes 的心脏跳在 etcd 上，etcd 的心脏是 Raft。一票（一个任期只投一次）、一任期（逻辑时钟代替物理钟）、一份日志（过半确认才提交）——三个概念入门共识协议，顺带看清它和 ZAB 的兄弟相。
ZooKeeper 的坑：会话超时与幽灵持有人
GC 停顿二十秒，ZK 判了持有人死刑，锁转手他人；进程复活后自以为还在持锁，继续往下游写——幽灵持有人登场。ZK 把协议级安全做到了位，却依然逃不过「进程不知道自己被冻结」的宿命。五个坑，各有各的缓解与代价。
ZooKeeper 分布式锁：临时顺序节点的排队艺术
创建临时顺序节点、看兄弟谁最小、只盯住前一个——三步走完，锁成了。互斥靠最小序号，防死锁靠会话蒸发，公平靠全局排队，防惊群靠「只盯前一个」。前五篇在 Redis 里拼命修的坑，ZK 方案里很多压根不存在。