一杯咖啡的时间，聊聊技术与成长
滑动窗口：把突刺磨平
固定窗口的 2 倍临界突刺，病根在「格子是死的」——窗口边界成了流量的免检通道。滑动窗口让统计区间跟着时间走，或者把格子切细统计最近 N 格，突刺被平滑掉，代价是内存与计算的加价。
限流第一课：固定窗口计数器
「下单接口每秒最多放 200 个」，这句话翻译成代码就是固定窗口计数器：按秒切格子，格子里数数，满了就拒。三行核心逻辑撑起第一道闸门，简单到不容易出错——但它有个藏在窗口边界里的坑。
爆单那天：雪崩是怎么发生的
周年庆半价日，10 点整活动上线，一分钟内 503 咖啡馆的系统从响应如飞到全站 502。慢查询打满连接池、线程排队堆积、不相关的服务连坐陪葬、重启再倒下——雪崩从来不是一瞬间的意外，是一条完整的灾难链。
收官复盘：一张作战地图串起整个系列
二十篇走完，从 110 块的糊涂账讲到 fencing 的终审判决。症状速查表、三条铁律、四步选型、十项检查——分布式锁与一致性协议的全部家当收进一张作战地图，下次互斥出问题，先翻这张图。
实战事故集锦：七个生产事故清单
永生锁停摆全店业务，一行 leaseTime 拆了看门狗，高频抢锁拖垮注册中心——七个生产事故，现象、根因、解法各一段，条条都有前文伏笔。事故清单是最贵的学费，也是最好用的面试题库与评审清单。
ZK 还是 etcd：云原生时代的协调服务选型
协议层面 ZAB 与 Raft 半斤八两，选型的天平其实压在时代与生态上：老栈躲不开 ZK，新栈顺手用 etcd，跑在 K8s 上的团队更是零成本白得一个 Raft 集群。本篇算清功能、运维、托管三本账。
fencing token：当持有人是个幽灵，下游凭什么拒绝它
锁的知情机制只能降低幽灵概率，挡不住冻结复活的客户端继续写入。真正的防线在下游：锁服务发单调递增令牌，存储只认见过的最大令牌——旧持有者的写入，无论它怎么自证清白，一条都进不来。
不用锁行不行：四个替代方案的正确打开方式
想加锁之前先停三秒：互斥的对象是数据还是逻辑？如果只是一行数据，版本号、唯一索引、行锁、队列串行化四个替代方案，个个比分布式锁便宜可靠。很多「抢锁」的冲动，其实是设计可以绕开的信号。
三种锁横向对比：一张选型地图
Redis 十万级 QPS 但共识缺位，ZK 共识过硬但千级吞吐，etcd 两头占优但要看生态脸色。选型不是比参数，是比场景：高频竞争给 Redis，低频高危给 ZK/etcd，强一致资金叠 fencing。多数团队的最优解出人意料地朴素。