这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
Redis 计数
当数据库行更新成为瓶颈时，Redis 的原子 INCR 是最直接的优化。它把高频计数写从数据库转移到内存系统中，显著提升吞吐。
like_count:{article_id} -> INCR本章主线
本章围绕 Redis 计数的完整生命周期展开：
- INCR 命令：理解 Redis 原子递增为什么适合计数。
- 持久化：讨论 Redis 数据如何落盘，以及宕机后的恢复风险。
- 冷启动：服务启动或缓存失效时，如何从数据库加载初始计数。
- 缓存一致性：Redis 计数如何回写数据库，展示值和存储值如何对齐。
Redis 解决了什么
Redis 的优势是：
- 单线程命令天然原子。
- 内存操作延迟低。
- 可以承载高频热点写。
- 适合和排行榜、限流等功能组合。
但 Redis 不是银弹。它引入了新的问题：宕机是否丢数据？数据库什么时候更新？Redis 和数据库不一致时，以谁为准？
写回策略
常见写回方式有：
- 同步双写：接口同时写 Redis 和数据库，简单但延迟高。
- 异步回写：先写 Redis，再通过任务批量落库，性能好但有延迟。
- 定时快照：周期性把 Redis 计数刷新到数据库。
点赞数通常可以接受短暂最终一致，因此更适合异步回写。但点赞记录本身仍然要保证幂等和可追踪。
本章完成标准
学完本章后，你应该能回答：
- Redis 计数为什么比数据库行更新快？
- Redis 计数丢失或回写延迟时，业务是否能接受？
- 冷启动和缓存击穿时如何恢复计数？
下一章会继续处理更极端的高并发场景。