标签：Feed 粉丝 微信 用户 模式 收件箱 朋友圈 消息
Feed流
更多内容移步个人blog : 来，教你设计朋友圈
什么是
朋友圈，微博，b 站抖音的推送，这些常用 app 的使用场景有一个共同的名词：Feed 流。
Feed 流可以理解为一个数据流，将 “X个发布者的信息” 通过 “关注关系” 传送给 “Y个接收者”，也就是将他的动态传给关注了他的你。
听上去似乎挺简单，不就是 A 发个动态，我关注了他，上线时把消息推给我嘛。嗯，有道理，且往下看。
设计
建表
首先，以微信朋友圈为例，请思考一下先仅考虑表，要怎么设计？
我们先抽象为最基础的三种表：用户表、消息表和关系表，用户表无需多说，关系表负责维护关注关系，如下即可：
| ID | user_id | follow_user_id | date | other… |
|---|---|---|---|---|
| 用户ID | 粉丝用户ID | 关注时间 | 其他 |
现在还剩消息表了：
| ID | message_id | content | date | user_id | other… |
|---|---|---|---|---|---|
| 消息ID | 消息内容 | 发送时间 | 发送者用户ID | 其他 |
每条消息都有发布人Id、时间、内容。好了，现在是不是可以开始撸码了？别急
只有一张表可以吗？
每一条消息都有 userId, 用户上线后从关系表里面拿到自己关注人的 id 集合，再去消息表里查询，拿到自己关注人的所有消息。
逻辑上当然可行，但明显效率特低，而且每次都要查两张表，数据量一大肯定要挂。
那就一人一张表
发送者发布消息后，会立即推给接收者，但接收者不一定在线，那么就需要有个地方存这个数据 – 收件箱。
每个人都有个收件箱，发布后的推到粉丝（好友）的收件箱，上线时根据时间读取自己收件箱，整挺好。
但再一想，假如用户量特大，这样成本就忒大了些，而且对于微博大 V 这种粉丝千万的热点用户, 每条消息都被冗余千万份到个人收件箱，明显也是不行的。
业务模式
现在可以想到，在不同的场景和用户规模下，业务的痛点也是不同的，那么就来分析下常见的 Feed 流的产品
| 类型 | 关注关系 | 是否有大V | 时效性 | 排序 |
|---|---|---|---|---|
| 微博类 | 单向 | 有 | n秒 | 时间 |
| 抖音类 | 单向（可无） | 有 | n秒 | 推荐 |
| 朋友圈类 | 双向 | 无 | 秒 | 时间 |
不难发现主要的差异就在于关注关系和排序方式
关注关系
- 单向：存在大V，但对时效性一般要求较低
- 双向：好友数量肯定有限，但都是熟人时效性要求就高
排序方式
- 时间：常见的排序方式，也容易理解和接受
- 推荐：抖音给你推的小姐姐，从全平台根据用户喜好推荐匹配内容，一般可以省掉
关注关系了。
消息同步方式
了解了业务模式的差异，回头再来看到底要建多少表。
对于消息表，可以做个总存储表（库），保证持久性，至于是NoSQL还是关系型数据库就看具体业务规模和研发能力了这里不做讨论。
接下来就只需要考虑每个用户接发消息收件箱和发件箱的设计。目前常见同步模式有三种：
推模式（写扩散）
发送者发布消息后，先存储到同步库即收件箱。
推模式又名写扩散，因为一个消息需要发送给多个粉丝，这条消息就会被复制多份，写放大，所以叫写扩散。该模式下，对同步库要求就是写入能力极强和稳定。毕竟读取时只需读下自己收件箱即可。
拉模式（读扩散）
发送者发送条消息后，不会立即推给粉丝，而是写入自己的发件箱，当粉丝或好友上线后再去关注者们的发件箱里面一一读取，这样每条消息只写入了一次，但读取数最多会和粉丝数一样，即读会放大，所以也叫读扩散。
该模式的读写比例刚好和拉模式相反，那么对发件箱的要求即：读取能力强。
tips: 开始设计 feed 流系统时，可能最容易想到的是拉模式，因为和用户的使用体感是一样的，但这种方式有不少问题。最大的问题是每个用户都要记录自己上次读到了关注者的哪条消息，如果粉了1000个小姐姐，那么这个单身狗就需要记录1000个位置信息，且这个量和关注量成正比，会远比全平台用户数大。
推拉结合
推模式在单向关系中，因为有大V，一条消息可能会扩散百万次，但很多用户可能都是僵尸号，就会导致资源浪费。
而拉模式，架构设计上比较复杂，同时每个用户需要记录自己关注者们的位置信息又是天量。
于是，推拉结合模式出来吧！
- 大部分用户的消息都是写扩散，毕竟大多用户都普普通通，能有多少好友，就推模式发到好友粉丝们的收件箱好啦。
- 大V用读扩散，你们这些粉丝都来我发件箱拉信息。
这样既避免了一定的资源浪费，又减少了很多设计的复杂度。当然了，整体还是比推模式复杂的。
实际场景
主要的消息表设计完成后，还有些实际场景需要考虑
点赞&评论
通过messageId关联即可
删除
如果是发送者删除，可以在消息表中物理或逻辑删除，接收者拉不到就行。
如果是朋友圈的屏蔽或者接收者的删除还有取关，那就在同步表即收件箱中删除即，同时可能更新关注关系。
搜索
搜索用户、内容，就需要使用支持全文分词搜索的数据库。
好了，总结下：
- 双向关系，就采用推模式写扩散。
- 单向关系，用户数少的话推模式也足够。
- 单向关系，用户数大，则采用推拉结合模式，可以先用推模式把架子搭起来再迭代。不要 仅采取拉模式。
另外，如果按推荐排序，那就是另一个问题了本文暂不讨论。
以及如何保证消息的可靠性，说起来就更多了。
主流应用
最后，再来看看这些主流的 app 怎么做的。
朋友圈
典型的Feed流，双向，有上限，排序按时间，能屏蔽能分组展示，妥妥的写扩散模式。
微博
微博关系是单向的，好多大V，排序也是时间，这时就需要推拉结合模式了。
头条
算是国内最早做推送的一批吧，俗称“大数据请记住我”。
标签：Feed,粉丝,微信,用户,模式,收件箱,朋友圈,消息 来源： https://blog.csdn.net/liyifan687/article/details/123090090
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。