来,教你设计朋友圈

Feed 流

什么是

朋友圈,微博,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,排序也是时间,这时就需要推拉结合模式了。

头条

算是国内最早做推送的一批吧,俗称“大数据请记住我”。

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇