这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
基础计数器设计
基础计数器从数据库开始，因为它最容易理解，也能暴露点赞系统的核心矛盾。
最简单的表设计可能是：
article(id, title, like_count)
user_like(user_id, article_id, created_at)用户点赞时，先写一条点赞记录，再更新文章点赞数。
本章主线
本章会先实现数据库计数方案，再逐步分析它的问题：
- 数据库方案：把点赞记录和点赞数都放在关系型数据库里。
- 并发问题：多个用户同时更新同一行时，行锁和覆盖写如何影响正确性。
- 乐观锁：用版本号减少覆盖更新，但吞吐仍然受热点行限制。
为什么要保留点赞记录
只有 like_count 不够。系统还需要知道：
- 当前用户是否已经点过赞。
- 用户取消点赞时应该扣哪一次。
- 如何防止重复点赞。
- 如何展示用户点赞历史。
因此，计数值和行为记录应该分开看。计数值服务展示，点赞记录服务状态和审计。
数据库方案的边界
数据库计数适合低并发或后台系统，但在高并发热点内容下会遇到瓶颈：
- 热门内容的同一行被频繁更新。
- 每次点赞都要写数据库，成本高。
- 并发更新需要锁或重试。
- 排行榜查询需要额外索引和排序成本。
学完本章后，你应该能解释：为什么数据库方案正确但不够快，以及为什么下一步要引入 Redis 计数。