39 | 信息流设计（一）：通用信息流系统的推模式要如何做？

信息流的架构演化 1、一开始很简单，两张表，一张存储关注关系 ，一张存储微博消息，用户A发微博就是在相应的微博消息表中写入一条即可，用户B读微博也很简单，就是先得到自己关注的用户列表，然后定时去存储微博消息表中去读取自己关注的微博展示出来即可，优点是只有一份存储，缺点也很明显，对于这张表的读操作太多了，并发过大。 2、改成推模式，即写扩散机制，用户A发送一条消息，除了写入微博消息表以外，还要写入关注它的所有的用户的收件箱中（这个可以用redis来实现），然后用户去收件箱中读取消息即可，优点就是自己读自己的消息，跟别人没有竞争，缺点是多余存储，在大V用户发微博消息中有延迟，同时写入次数太多了，同时取消关注什么的也比较难操作。 3、后面改成了推拉结合的方式，即对于大V用拉模式，对于普通的用户继续用推模式。 4、后面出现了基于时间分区的拉模式，个人觉得可以结合推模式来进行相应的弥补。

我觉得推模式最大的问题是没有做到按需传递信息，可能一个粉丝的用户中，只有很少比例才需要较高的时效性，这些用户不应该消耗太多的系统资源。 此外，推模式中的写操作太多了，一个人发送，其他人在本质上都是读取这条消息，却也引发了写入操作。 应该把新的信息写入到若干存储（包括缓存上），然后选择适当的策论，让用户去这些存储上读取数据。这样可以大大降低写入操作的数量。

老师，我有个疑问，我们是关注文档，使用推模式，新增和更新文档时，就查询有哪些用户关注了这篇文档，然后新增或者更新这些用户的收件箱。这样导致有个问题，一个是写入和更新操作比较多，另外一个是有重复消息或者消息乱序时，会重复更新用户动态或者把用户的动态更新为更早的。因为我们的关注用户量比较少，所以目前还能使用推模式。我想过使用缓存来缓存文档id和操作时间，每次新增或者更新动态时先比较下操作时间，但就需要加分布式锁。这种情况老师有什么建议么？

1.目前我公司的产品，我的做法没用数据库，全部是用redis来存储，用的就是推的模式。一个用户最多关注也就1万多个用户，当发了一条微博，就扔到消息队里面，消息队列再去拉取用户所有关注的人。一个一个放到对应粉丝的redis中。

推的时候只给在线用户推一个未读消息数的提示，然后用户在点击未读消息的时候再去拉消息列表。推拉结合着用。

推模式中可以给用户分优先级，优先推送优先级高的用户的方式来提升用户体验。

1.根据分组又建一张表。应该不存全量数据吧，太浪费空间。存与全局收件箱的id映射就好了吧。 2.这个推模式确实有点恐怖。大量写操作简直就是噩梦。硬刚实现这种大量写是不现实的。所以改成拉模式，在登陆时按需拉取。但全量的按需拉取，登陆时的信息同步延迟也是不能接受，所以推拉结合以及更细力度的操作，满满都是权衡。长见识。 3.拉可以批量可以压缩，其实优化的空间会大点。

老师，对于信息流的缓存存储有什么比较好的建议呢？因为考虑到分页、过滤等筛选条件。

不理解为什么基于推模式要给每个用户甚至每个分组存储一份完整的消息，为什么不能用存储关联关系，计算得到推送的消息呢？

跟微博比，我們的信息流弱爆了，目前都是用elasticsearch做信息流拉模式，閱讀之後就給當前頁的數據批量設置狀態，拉到下一頁就給下一頁數據更新狀態