这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
高并发优化
Redis 计数能显著提升性能，但热门内容仍然会制造局部热点。假设一条视频在直播间或首页被推荐，短时间内涌入几十万次点赞请求，单个 Redis key、单个服务实例、单条回写链路都可能成为瓶颈。
本章主线
本章讨论高并发下的削峰和扩展：
- 本地缓存：读请求不必每次都打到 Redis，降低读放大。
- 分片计数：把一个热点计数拆成多个 shard，减少单 key 压力。
- 合并写：把大量增量聚合后批量回写数据库。
这些方案都在做同一件事：把瞬时压力拆散、聚合或延后。
读写分离
点赞系统有两类请求：
- 写：点赞、取消点赞。
- 读：展示点赞数、判断当前用户是否已点赞。
展示点赞数可以使用缓存或近似值，不必每次查最精确数字。用户是否点赞过则需要更准确，因为它影响按钮状态和幂等处理。
分片计数的取舍
分片计数可以把：
like_count:article_1拆成：
like_count:article_1:shard_0
like_count:article_1:shard_1
...写入时随机或按用户路由到某个分片，读取时汇总多个分片。这样写压力降低，但读取成本变高，且需要处理汇总缓存。
合并写的边界
合并写能减少数据库压力，但会带来延迟。如果 Redis 已经加了 1000，数据库还没回写，后台报表可能看到旧值。是否可接受取决于场景：
- 用户前台展示可以读 Redis。
- 后台统计可以接受延迟。
- 财务或结算类计数不应使用这种弱一致方案。
本章学完后，你应该能根据热点程度选择本地缓存、分片计数和合并写，而不是盲目堆缓存。