Feed 流模型

新的需求

系统运行稳定后，产品经理提出了新需求：

【需求文档】用户个人中心

功能 1：我点赞的文章
- 展示用户点赞过的所有文章
- 按点赞时间倒序排列
- 支持分页

功能 2：点赞过这篇文章的用户
- 展示点赞过某篇文章的所有用户
- 按点赞时间倒序排列
- 最多显示 100 个

功能 3：好友动态
- 展示好友最近的点赞动态
- 实时更新

这就是 Feed 流需求。

什么是 Feed 流？

Feed 流定义

Feed 流（信息流）：
- 按时间顺序排列的内容流
- 持续更新的内容展示
- 用户可滚动浏览

常见场景：
- 微信朋友圈
- 微博首页
- 今日头条推荐
- Instagram

Feed 流类型

类型 1：Timeline 模型（时间线）

特点：
- 按内容发布时间排序
- 用户看到的是最新内容
- 算法简单，实现容易

示例：
- 微信朋友圈
- 微博关注页

类型 2：推荐模型

特点：
- 按算法推荐排序
- 个性化内容推荐
- 算法复杂，实现困难

示例：
- 今日头条
- 抖音推荐页
- Facebook Feed

点赞 Feed 流的特点

点赞 Feed 流：
- 属于 Timeline 模型
- 按点赞时间排序
- 用户主动操作产生
- 实时性要求高

与普通 Feed 流的区别：
1. 不是发布内容，而是互动行为
2. 需要双向关联（用户→文章，文章→用户）
3. 数据量可能更大（每个点赞都是一条记录）

数据模型设计

关系分析

用户点赞文章，产生两个关系：

关系 1：用户 → 文章
- 用户点赞了哪些文章？
- 用于"我点赞的文章"功能

关系 2：文章 → 用户
- 哪些用户点赞了这篇文章？
- 用于"点赞过这篇文章的用户"功能

数据结构设计

方案 1：关系表

数据设计要点

• 核心是在 article_likes 里保存业务事实，而不是把规则散落在应用逻辑里。
• 索引服务于高频查询，重点是缩小扫描范围，而不是堆更多字段。
• 关键字段包括 id、article_id、user_id、created_at，它们决定后续查询和管理能力。

查询 SQL：

数据设计要点

• 查询目标是快速定位状态、任务或资源，避免在关键路径上做大范围扫描。

优点：

• 实现简单
• 数据一致性好
• 支持复杂查询

缺点：

• 查询性能随数据量增长而下降
• 分页查询慢（深分页）
• 数据库压力大

方案 2：Redis List

优点：

• 性能好
• 实现简单
• 支持分页

缺点：

• 去重困难（List 不自动去重）
• 内存占用大
• 不支持复杂查询

方案 3：Redis Sorted Set（推荐）

优点：

• 自动排序（按时间戳）
• 自动去重
• 支持范围查询
• 性能好

缺点：

• 内存占用相对大
• 不支持复杂查询

推荐：使用 Sorted Set

完整方案

基础功能

集成到点赞功能

性能优化

优化 1：Pipeline 批量查询

优化 2：缓存热门数据

优化 3：懒加载

课后练习

练习 1

如何实现”好友的点赞动态”功能？

练习 2

如何处理 Feed 流的”分页空洞”问题？

分页空洞：
- 用户浏览第 1 页（20 条）
- 其他用户删除了 5 条内容
- 用户浏览第 2 页
- 可能出现重复或遗漏内容

练习 3

如何实现 Feed 流的”实时更新”？

练习 4

如何优化 Feed 流的存储空间？

练习 5

如何实现 Feed 流的”去重”？

思考题

1. 如何实现”双向关注”的 Feed 流（只看互关好友的动态）？

2. 如何处理 Feed 流的”已读/未读”状态？

3. 如何实现 Feed 流的”置顶”功能？

💡 提示：这些问题没有标准答案，建议结合实际情况深入思考。