这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
点赞记录
存储挑战
实现 Feed 流后，数据量快速增长。
数据增长：
第 1 周：
- 用户数：1,000
- 点赞总数：10,000
- 平均每用户：10 条点赞记录
第 4 周：
- 用户数：10,000
- 点赞总数：500,000
- 平均每用户：50 条点赞记录
第 12 周：
- 用户数：50,000
- 点赞总数：5,000,000
- 平均每用户：100 条点赞记录
问题：
- 存储成本快速增长
- 查询性能下降
- Redis 内存压力大需要优化存储方案。
存储方案对比
方案 1：全量存储
优点：
- 实现简单
- 数据完整
缺点：
- 存储成本高
- 内存占用大
存储成本估算：
假设：
- 用户数：50,000
- 平均每用户：100 条点赞记录
- 每条记录：16 字节（article_id: 8 bytes + score: 8 bytes）
总存储：
50,000 × 100 × 16 = 80 MB
如果增长到：
- 用户数：500,000
- 平均每用户：200 条
总存储：
500,000 × 200 × 16 = 1.6 GB方案 2：限制存储
优点：
- 存储成本可控
- 内存占用稳定
缺点：
- 旧数据会丢失
- 不支持查看历史记录
适用场景：
- 只需要最近的记录
- 不需要完整历史
方案 3：分层存储（推荐）
优点：
- 存储成本优化
- 查询性能好（热数据）
- 支持历史查询（数据库）
缺点：
- 实现复杂
- 需要多层存储
存储成本对比：
全量存储：
- Redis：1.6 GB
- 数据库：5 GB
限制存储：
- Redis：200 MB
- 数据库：5 GB
- 节省：87.5%
分层存储：
- Redis（热）：50 MB
- Redis（温）：100 MB
- 数据库：5 GB
- 节省：90.6%数据迁移
从数据库迁移到 Redis
增量同步
性能优化
优化 1：压缩存储
优化 2：Bitmap 存储
Bitmap 优缺点：
优点：
- 存储空间极小（每个用户只占 1 bit）
- 查询速度快
- 适合布尔值（点赞/未点赞）
缺点：
- 不支持时间排序
- 不适合稀疏数据
- 文章 ID 必须连续课后练习
练习 1
如何实现点赞记录的”软删除”？
参考答案(3 个标签)
数据存储软删除设计模式
方案：添加删除标记
练习 2
如何实现点赞记录的”归档”？
参考答案(3 个标签)
数据归档存储优化生命周期
方案：自动归档旧数据
练习 3
如何实现点赞记录的”统计分析”？
参考答案(3 个标签)
数据分析统计聚合
方案：定期统计
练习 4
如何实现”批量导入”点赞记录？
参考答案(3 个标签)
数据导入批量操作性能
方案：使用 Pipeline 批量导入
练习 5
如何实现”跨天”的点赞记录查询？
参考答案(3 个标签)
数据查询时间范围分片
方案：按日期分片存储
思考题
-
如何设计一个支持”撤销”的点赞系统（可以撤销任意时间的点赞）？
-
如何实现”点赞提醒”（文章作者收到点赞通知）？
-
如何优化”超级用户”的 Feed 流存储（点赞数超过 10000）？
💡 提示：这些问题没有标准答案，建议结合实际情况深入思考。