这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
分布式计数
当计数服务扩展到多实例、多机房或多 Redis 节点时，问题从“单点性能”变成“分布式一致性”。点赞和取消点赞需要幂等，多个实例不能把同一次操作重复计算，也不能因为并发导致记录和计数不一致。
本章主线
本章会讨论三个常见工具：
- Lua 脚本：把检查和更新放到 Redis 原子执行。
- 分布式锁：保护关键资源，但要谨慎使用。
- Redlock：理解 Redis 分布式锁方案的适用边界和争议。
点赞幂等
用户重复点击、网络重试、客户端重发都会导致同一次点赞请求多次到达。系统需要保证：
如果用户已经点赞，不再重复 +1
如果用户没有点赞，写记录并 +1这两个动作要么一起成功，要么一起失败。可以用 Redis Set 记录用户点赞状态，再用 Lua 脚本原子判断和更新。
锁不是默认答案
分布式锁可以保护临界区，但会带来：
- 锁等待增加延迟。
- 锁过期导致并发进入。
- 锁服务故障影响业务。
- 锁粒度过大降低吞吐。
点赞系统更常见的思路是幂等、原子脚本和最终一致补偿，而不是所有操作都加锁。
一致性边界
分布式计数要明确哪些数据必须一致：
- 用户点赞状态必须准确，否则按钮和重复点赞会错。
- 总点赞数允许短暂延迟，但不能长期漂移。
- 排行榜可以秒级最终一致。
理解这个边界后，系统就能把强一致用在关键状态，把最终一致用在展示和统计。