1.设计信息流系统的关注点

微博：信息系统（时间线）

用户A关注用户B，用户A就需要在信息流中，用户B可以看到最新的内容

这是微博系统的基本逻辑，也是它能够让信息快速流通、快速传播的关键

2.如何基于推模式实现信息流系统

数据延迟，关注的人发了微博后多久可以看到
支撑高并发访问，微博每秒几十万次请求
信息的拉取性能，性能卡点（聚合数据很慢）\
1. 微博数据
2. 用户数据
3. 点赞、评论、转发数汇总

解法：推+拉（微博）

2.1什么是推模式

推模式是指用户发送一条微博后，主动将这条微博推送给他的粉丝，从而实现微博的分发，也能以此实现微博信息流的聚合。

推模式：类似邮箱，向每个用户发送邮件

//更新信息 insert into outbox(userId, feedId, create_time) values("A", $feedId, $current_time); //写入A的发件箱 insert into inbox(userId, feedId, create_time) values("B", $feedId, $current_time); //写入B的收件箱 insert into inbox(userId, feedId, create_time) values("C", $feedId, $current_time); //写入C的收件箱 insert into inbox(userId, feedId, create_time) values("D", $feedId, $current_time); //写入D的收件箱   //查询信息 select feedId from inbox where userId = "B";

优化点：将数据缓存起来，每次从缓存中读取

存在的问题
- 延迟过高
  - 用户接收不到最新消息，遍历一次全量用户延迟很高，并发量也很高
    - 优化：使用消息队列削峰填谷
  - 启用多个线程并行写入微博消息
  - 写性能更好的数据库存储引擎

网易微博的时候就是采用推模式来实现微博信息流的。当时为了提升数据库的插入性能，我们采用了 TokuDB 作为 MySQL 的存储引擎，这个引擎架构的核心是一个名为分形树的索引结构（Fractal Tree Indexes）

优点：存储更小

缺点：删除和查询性能更差

3.推模式存在的问题和解决思路

3.1表结构设计

Feed 表，这个表主要存储微博的基本信息，包括微博 ID、创建人的 ID、创建时间、微博内容、微博状态（删除还是正常）等等，它使用微博 ID 做哈希分库分表

另外一张表是用户的发件箱和收件箱表，也叫做 TimeLine 表（时间线表），主要有三个字段，用户 ID、微博 ID 和创建时间。它使用用户的 ID 做哈希分库分表。

数据量大怎么办：定期地清理用户的收件箱，比如只保留最近 1 个月的数据就可以了

删除微博：删除所有用户的收件箱

在读取微博的时候判断是否关注该用户，没有就忽略这个微博

3.2适用的场景

适用于用户粉丝邮箱的场景，微信朋友圈....

即使全部推送也没有特别大的数据量

4.课程小结

推模式就是在用户发送微博时，主动将微博写入到他的粉丝的收件箱中

送信息是否延迟、存储的成本、方案的可扩展性以及针对取消关注和微博删除的特殊处理是推模式的主要问题

推模式比较适合粉丝数有限的场景\

37消息推送（主动写）