feed流拉取,读扩散,究竟是啥?
from:https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651961214&idx=1&sn=5e80ad6f2a278529c395e445029d8f63&chksm=bd2d02a28a5a8bb4f8622b1bff1cf87fc9adb510117dd2cf93fedd01fdc5d5ace7557a03f3b1&scene=21#wechat_redirect 任何脱离业务的架构设计都是耍流氓。 ? 哪些产品是feed流典型业务? 答:微博,微信朋友圈,Pinterest是典型的feed流业务,系统中的每一条消息就是一个feed。 ? 这类业务的特点是:
? 这类业务的典型动作是:
? 这类业务的核心元数据是:
? feed流的“拉取”与“推送”实现,是个怎么回事? 答:feed流业务最大的特点是“我们的主页由别人发布的feed组成”,获得朋友圈消息feed流集合,从技术上说,主要有“拉取”与“推送”两种方式。feed流的推与拉主要指的是这里。 ? 今天将简述拉模式(圈内说的较多的是“读扩散”)的核心数据结构,核心流程,优缺点。 ? 例如:某feed系统里有ABCD四个用户,其中:
其关系存储又包含关注关系与粉丝关系,“A关注了BC,D关注了B”的潜台词是“B有两个粉丝AD,C有一个粉丝A”。 ?
每一个用户,都有一个feed队列,记录自己曾经发布的所有feed数据。 ? 在拉模式中,发布一条feed的流程非常简单,例如C新发布了一条msg12: 此时只需往C的feed队列里加入一条feed即可。 ? 在拉模式中,取消关注的流程也非常简单,例如A取消关注C: 此时只需要在A的关注列表里删除C,并在C的粉丝列表里删除A即可。 ? 在拉模式中,用户A获取“由别人发布的feed组成的主页”的过程比较复杂,此时需要:
list<gz_uid> = select uid from GZ where uid=A
list<msg> = NULL; for(uid in list<gz_uid>){ ???????? list<some_msg> =? ? ? ? ? ? ? select * from F where uid=$uid offset | limit ???????? list<msg> += list<some_msg>; }
sort_msg_by_time(list<msg>); get_one_page(list<msg>,page_num); ? feed流的拉模式(“读扩散”)有什么优缺点? 优点:
? 缺点也显而易见:
? 在拉模式中,系统的瓶颈容易出现在“用户所发布feed列表”的读取上,而每个用户发布feed的频率其实是很低的,此时,架构优化的核心是通过缓存降低数据存储磁盘IO。 ? 当用户量、数据量、并发量数据逐步增加之后,拉模式会慢慢扛不住了,需要升级优化,但对于“取消关注”与“发布feed”这两个写流程又会有冲击和影响,具体架构应该如何迭代,下一章和大家分享(额,今天笔记本没电了)。 ? 架构,不只是设计出来的,更是演进而来的。 ? 填坑篇1:《系统通知,究竟是推还是拉?》 填坑篇2:《状态同步,究竟是推还是拉?》 填坑篇3:《网页端消息,究竟是推还是拉?》 填坑篇4:《群已读回执,究竟是推还是拉?》 填坑篇5:《群消息,究竟存1份还是多份?》 ? 朴素的设计,也有其适应的业务阶段。 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |