微博架构02

业务中很多需求都会用到类似feed流的架构。
例如

• 微信朋友圈
• 微博
• 动态
• 1对N消息。

一般feed流的架构实现有下面几种。
假如现在的业务场景是微博，然后当前的数据情况是：

用户A关注了用户B和C，用户D关注了用户B
用户B发了微博A，B，用户C发了微博C，D

优缺点：

• 实现较复杂
• 空间占用较多，一条微博需要插入1+N条记录（N是粉丝用户数）。如果N是几十w或者几百w，对数据库压力非常大，包括空间占用，插入或删除耗时，索引建立等。
• 第2个接口可以用索引，所以查询很快

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

拉的方式缺点是查询慢

推
推的方式需要三张表
微博表（微博ID，微博内容，发布人）
粉丝表（粉丝ID）
feed表（微博ID，微博内容，接收人）
a）A发布微博，写入微博表
b）后端查询A的粉丝表，将微博内容和接收人写入feed表
c）客户端查询关注表，再查询feed表获取关注的内容

推的方式缺点是数据量大，A有n个粉丝，就需要往feed表中写入n条记录，没发布一次微博，就产生n+1条数据。当n为几百万、几千万时，数据库的压力就很大。