这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
完整系统
到这里，点赞计数器已经从一个数字字段演进成完整互动系统：
点赞请求 -> 幂等校验 -> Redis 计数 -> 异步回写
-> 点赞记录 -> Feed 展示 -> 排行榜更新 -> 风控与审计最终架构
一次点赞请求可以这样处理：
- 网关完成用户鉴权和基础限流。
- 点赞服务校验用户是否已经点赞。
- Redis Lua 脚本原子写入点赞状态并更新计数。
- 点赞事件进入消息队列。
- 异步消费者回写数据库、更新排行榜、生成 Feed 事件。
- 前台展示从 Redis 或汇总缓存读取点赞数。
- 定时任务对账 Redis、数据库和行为日志，修复差异。
这条链路把高频写留在 Redis，把慢操作放到异步链路，同时保留行为记录用于幂等和追踪。
关键决策
- 计数值和点赞记录分离：计数服务展示，记录服务幂等和关系查询。
- Redis 承载高频计数：提升吞吐，但需要持久化、回写和对账。
- 热点内容分片计数：缓解单 key 压力，但增加汇总复杂度。
- 排行榜异步更新：降低接口延迟，接受秒级最终一致。
- Feed 展示去重：点赞事件要服务用户体验，而不是逐条刷屏。
一致性分层
点赞系统的关键是按场景分层：
| 场景 | 一致性要求 |
|---|---|
| 用户是否已点赞 | 强一些，影响按钮状态和幂等 |
| 点赞数展示 | 可短暂最终一致 |
| 排行榜 | 秒级最终一致 |
| 离线统计 | 分钟级或小时级一致 |
这样才能在性能和正确性之间取得平衡。
上线检查清单
- 点赞和取消点赞是否幂等？
- 重复请求、网络重试是否会导致重复计数？
- Redis 宕机或丢失后是否能从数据库恢复？
- Redis 计数和数据库是否有回写和对账？
- 热点内容是否有分片或限流方案？
- 排行榜是否能处理分页、延迟和防刷？
- Feed 展示是否能合并和去重点赞事件？
- 是否监控点赞成功率、延迟、回写积压和数据差异？
课程总结
点赞计数器的本质是高频互动数据系统。它既有计数性能问题，也有用户状态、一致性、Feed 展示、排行榜和风控问题。
当你设计计数系统时，先问：
- 这个数字是否必须实时绝对准确？
- 用户行为记录和展示计数是否应该分离？
- 高并发热点在哪里？
- 数据不一致时如何发现和修复？
能回答这些问题，就能把一个简单点赞按钮设计成可扩展的生产级系统。