个人Feed流方案演进-CSDN博客

作者：贝聊研发部-叶志伟

1、需求背景

天时人事日相催,冬至阳生春又来

作为程序员，终日废寝忘食地写代码，奈何需求源源不绝，何时是个头，该抽时间沉淀一下，于是在冬至这天，总结与分享贝聊现有的班级动态以及向个人feed流演进的方案，由于尚未实践，需求还在变更的路上，这是一场纸上谈兵式的头脑风暴。如有错误或者有更好的方法欢迎指正和指点一下。

2、现有的动态

2.1、班级动态

老师或家长发布和查看动态都是以班级为单位的，左图是老师发布动态，右图是家长查看动态，需求比较简单明了，有动态实体、点赞和回复。

表的设计如下，困难点在于亿级的数据量，我们使用的是阿里云的DRDS，详情可参考贝聊亿级数据库分库分表实践，这里不再叙述。

2.2、其他动态

考勤、食谱、广告等争先展示在用户面前，于是乎在查询出班级动态后，再查询其他数据插入到动态列表里返回给用户，顺理成章的这么做。但仔细想，动态列表的维度已经开始变细，考勤是宝宝进出幼儿园时打卡产生，已经细化到宝宝，每个家长看到的开始不一样了。
再后来需要向家长展示更多宝宝个性化的动态，继续沿用现有的设计吗？似乎可行，再去查询然后合并插入到动态列表，第一反应是，这么多RPC调用会不会很慢？继而想到的优化方案是并行去查询，打日志看速度确实有所提升。但这样子随着时间和版本迭代，这块代码越来越臃肿，而用户读写操作的比例是比较大的，每次这样去读还是比较耗费资源，有没有更优雅的方式去实现？于是个人feed流方案就此诞生。

3、个人feed流几种实现方式

本节介绍个人feed流的几种常用的实现方式，以微博为例子，有了解的同学可以跳过。

3.1、读扩散（拉模式）

用户拉取自己动态时，检索用户的关注表，然后根据关注表检索被关注者新发的动态，写入到自己的feed流。

优点：设计简单。
缺点：查询用户个人动态时检查是否需要去拉取，关注者多时很大概率需要拉取，速度慢。

3.2、写扩散（推模式）

当一个用户发微博，先往实体表里插入一条记录，同时也对应到这个用户的粉丝表，为每个粉丝插入一条动态。

优点：查询简单，从自己的feed流分页查询即可。
缺点：follower很多时，产生大量数据，写压力大，需保证都写成功。

3.3、读写结合

大V发动态，只同步发布动态给在线（或者活跃）的粉丝，离线（非活跃）的粉丝上线后，再去拉取动态，来完成推与拉。

优点：减少写扩散的压力，在线（或者活跃）用户有较快的读速度
缺点：离线（或者非活跃）用户下次上线的首次拉取速度较慢

4、方案的选择与设计

首先需要说明的是，如果实施这个方案，客户端会做改版，旧版的兼容问题会带来不少问题。

一个班级相关的家长和老师数量比较少，数量在百级别。
运营发布的推广范围比较广，可以指定地区、幼儿园。
其他更复杂的业务场景。

单一的读和写扩散都有限制，不同的场景使用不同的方式可以更加灵活，所以选择读写结合的方式。再者，读扩散和写扩散在设计上是独立的两个模块，选择其一以后也很容易扩展。

4.1、双写

旧表的主键是自增的，新的方案里为了保证动态实体和写扩散到个人feed流保持一致性和幂等性，需要生成一个全局的唯一id，如果失败了下次重新插入时不会重复。
旧表是针对班级动态，新的方案里动态有多种类型，字段不满足新业务需求
新业务的一些数据不能出现在旧版APP

主要基于以上这几点，决定使用新的DRDS，这会带来一个问题，旧版APP依然使用旧的接口以及旧的数据库，完全保留原来的逻辑，新版APP界面改版使用新的接口以及新的数据库，两边就需要同步数据，旧版APP产生的数据也要写到新数据库，新版APP产生的数据也要写到旧数据库，双写有很多细节的逻辑需要注意，例如数据的一致性，要用分布式事务吗？两边的同一条动态的id不一样，要做个id映射表，在同步回复和点赞时才能找到对应的动态。