来,设计个微信朋友圈-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流相关推荐
- 请你设计一个微信朋友圈点赞的测试用例
请你设计一个微信朋友圈点赞的测试用例 参考回答: 功能测试: 点赞某条朋友圈,验证是否成功 接口测试: 点赞朋友圈,验证朋友能否收到提示信息 性能测试 点赞朋友圈,是否在规定时间显示结果,是否在规定时 ...
- 如果让你设计一个微信朋友圈,你怎么设计
这个问题当时把我问的萌币了 我想他大概是考察这切入点吧 1,分布式事务?CAP逻辑 C:一致性?的考察,比如我发了一个微信朋友圈,其他人都能及时的看到 2,微信朋友圈的可见和不可见的关系,就比如从我的 ...
- 从一个BUG聊微信朋友圈设计
Y说 最近生活方式发生了一点变化.搬家了,住的地方离公司更近了. 这就让我多了很多的操作空间,比如早上起来跑个步啥的.跑完步还能有点时间写博客,所以紧赶慢赶花了几个早上把这篇很早之前就想写的文章写出来 ...
- 微信朋友圈点赞用例设计
微信朋友圈点赞用例设计
- 浅谈微信朋友圈的架构设计
微信朋友圈是一种社交媒体应用,主要功能是让用户分享图片.视频和文字等内容,并与好友互动.一个基本的微信朋友圈设计方案: 数据库设计 微信朋友圈需要存储大量的图片和视频等多媒体数据,因此需要设计一个高效 ...
- 【思考】微信朋友圈的基本数据结构该怎么设计?
微信朋友圈的基本数据结构该怎么设计,即可以有效的实现权限控制,又可以不影响性能? 微信朋友圈的一条消息的数据包括了文字.图片.发布时间.地理位置.但如果要考虑权限控制和性能,则需要单独讨论其他数据字段 ...
- 班旗怎么用软件设计,微信朋友圈投票软件[必看]如何制作
随着微信朋友圈投票活动的增多,每个人都在微信上投票.如果你经常在朋友圈中进行游说,就会引起每个人的不满.如何交朋友圈投票软件 [必看] 大师分享一个完整的体验 朋友圈投票软件制作过程适合所有人. 微信 ...
- 揭秘微信朋友圈这种信息推流背后的系统设计
1.引言 信息推流(以下简称"Feed流")这种功能在我们手机APP中几乎无处不在(尤其是社交/社群产品中),最常用的就是微信朋友圈.新浪微博等. 对Feed流的定义,可以简单理解 ...
- 微博2面:微信朋友圈是怎么实现的?
点击上方蓝字关注趣学程序! 来源:r6d.cn/E8pb 差不多十年前,随着功能机的淘汰和智能机的普及,互联网开始进入移动互联网时代,最具代表性的产品就是微博.微信,以及后来的今日头条.快手等.这些移 ...
最新文章
- 企业在管理系统方面要有主动权
- WINCE6.0组件选择说明
- Pagination(分页) 从前台到后端总结
- 现代程序设计 作业7 - 更加简单的题目
- 在 Mac 上的 Keynote 讲演中如何更改共享演示文稿的设置?
- 2012年之前Mac Book pro 安装新系统macOS 10.15 Catalina 制作U盘启动盘
- mac osx终端命令大全
- 深度学习常用资料整理
- 如何使用SQL判断身份证号码第18位是否符合规则
- 让机器人更安全——(5.总结与展望)
- Windows10系统优化(批处理)
- qq飞车显示服务器维护中,QQ飞车手游更新出现异常怎么办?更新异常原因及解决方法技巧...
- 知识图谱从入门到应用——知识图谱推理:基础知识
- 2021年网络空间安全学院预推免面试经验总结
- JavaScript中的扁平化数据转换为树形结构、树形结构扁平化数据
- Webview--如何让加载进来的页面自适应手机屏幕分辨率
- 南卫理公会大学 计算机排名,南卫理公会大学全球排名及其优秀校友
- MATLAB线形规划函数linprog、intlinprog与二次规划函数quadprog
- mac重新登陆前部分账户服务将不可用
- 海南考研二战心得体会