2019-12-23信息流的架构演化
1、一开始很简单，两张表，一张存储关注关系 ，一张存储微博消息，用户A发微博就是在相应的微博消息表中写入一条即可，用户B读微博也很简单，就是先得到自己关注的用户列表，然后定时去存储微博消息表中去读取自己关注的微博展示出来即可，优点是只有一份存储，缺点也很明显，对于这张表的读操作太多了，并发过大。
2、改成推模式，即写扩散机制，用户A发送一条消息，除了写入微博消息表以外，还要写入关注它的所有的用户的收件箱中（这个可以用redis来实现），然后用户去收件箱中读取消息即可，优点就是自己读自己的消息，跟别人没有竞争，缺点是多余存储，在大V用户发微博消息中有延迟，同时写入次数太多了，同时取消关注什么的也比较难操作。
3、后面改成了推拉结合的方式，即对于大V用拉模式，对于普通的用户继续用推模式。
4、后面出现了基于时间分区的拉模式，个人觉得可以结合推模式来进行相应的弥补。展开作者回复: 👍
9
2020-01-21老师，我有个疑问，我们是关注文档，使用推模式，新增和更新文档时，就查询有哪些用户关注了这篇文档，然后新增或者更新这些用户的收件箱。这样导致有个问题，一个是写入和更新操作比较多，另外一个是有重复消息或者消息乱序时，会重复更新用户动态或者把用户的动态更新为更早的。因为我们的关注用户量比较少，所以目前还能使用推模式。我想过使用缓存来缓存文档id和操作时间，每次新增或者更新动态时先比较下操作时间，但就需要加分布式锁。这种情况老师有什么建议么？作者回复: 如果关注的人数不多，消息写入没有瓶颈的话，可以继续使用推模式。消息的乱序问题可以通过别的方式解决，比如如果使用Kafka，那么可以把一个人的消息写入到一个固定的partition
2
2019-12-23我觉得推模式最大的问题是没有做到按需传递信息，可能一个粉丝的用户中，只有很少比例才需要较高的时效性，这些用户不应该消耗太多的系统资源。
此外，推模式中的写操作太多了，一个人发送，其他人在本质上都是读取这条消息，却也引发了写入操作。
应该把新的信息写入到若干存储（包括缓存上），然后选择适当的策论，让用户去这些存储上读取数据。这样可以大大降低写入操作的数量。作者回复: 是的
1 2
2019-12-23跟微博比，我們的信息流弱爆了，目前都是用elasticsearch做信息流拉模式，閱讀之後就給當前頁的數據批量設置狀態，拉到下一頁就給下一頁數據更新狀態作者回复: 存在即合理~
1 1
2019-12-281.根据分组又建一张表。应该不存全量数据吧，太浪费空间。存与全局收件箱的id映射就好了吧。
2.这个推模式确实有点恐怖。大量写操作简直就是噩梦。硬刚实现这种大量写是不现实的。所以改成拉模式，在登陆时按需拉取。但全量的按需拉取，登陆时的信息同步延迟也是不能接受，所以推拉结合以及更细力度的操作，满满都是权衡。长见识。
3.拉可以批量可以压缩，其实优化的空间会大点。展开作者回复: 一般收件箱都是记录ID，也就是对应关系，但即使这样，写入量依然很高
2019-12-23老师，对于信息流的缓存存储有什么比较好的建议呢？因为考虑到分页、过滤等筛选条件。作者回复: 微博是只存储发件箱，并且是按照时间来分为多级缓存，比如把最近五天的微博ID存储到一组缓存里面，所以可以存储全量。
考虑过滤的话，也会存储一些用于过滤的flag信息
2019-12-23不理解为什么基于推模式要给每个用户甚至每个分组存储一份完整的消息，为什么不能用存储关联关系，计算得到推送的消息呢？作者回复: 是需要存储微博ID，不存储微博的内容，我不知道你提到的存储关联消息指的是不是这个
2019-12-23推模式中可以给用户分优先级，优先推送优先级高的用户的方式来提升用户体验。作者回复: 是的，推拉结合 是这样的