数据人看Feed流-架构实践( 八 )_背景Feed流：可以理解为信息流

对于关系服务，其写入操作是建立关系和删除关系，读取操作是获取关系列表，逻辑上仅需要一个KV系统。如果数据量较少可以使用RDS ，如果数据量较大推荐使用HBase 。如果对关系的QPS压力大可以考虑用Redis做缓存。

图4 用户关系存储

讲到Feed流一定会有关于推模式和拉模式的讨论，推模式是把消息复制N次发送到N个用户的收信箱，用户想看消息时从自己的收信箱直接获取。拉模式相反，生产者的消息写入自己的发信箱，用户想看消息时从关注的M个发信箱中收集消息。

图5 消息传递的推模式和拉模式

推模式实现相对简单，时效性也比较好。拉模式要想获得好的性能需要多级的缓存架构。推模式重写，拉模式重读， Feed流场景下写的聚合效果要优于读，写可以大批量聚合。 N越大，写入造成的数据冗余就越大。 M越大，读消耗的资源越大。

随着业务的增长，推模式资源浪费会越发严重。原因在于两点：第一存在着大量的僵尸账号，以及大比例的非活跃用户几天或者半个月才登陆一次；第二信息过载，信息太多，重复信息太多，垃圾信息太多，用户感觉有用的信息少，消息的阅读比例低。这种情况下推模式相当一部分在做无用功，白白浪费系统资源。

数据人看Feed流-架构实践( 八 )