1.如何使用拉模式设计信息流系统
推模式无法应对大范围的好友关系（消息推送延迟、存储成本高、方案可扩展性差等问题）
什么是拉取：用户主动拉取他关注的所有人的微博，按照微博发布时间，进行排序和聚合之后，生成信息流数据的方法
//新增代码
insert into outbox(userId, feedId, create_time) values("B", $feedId, $current_time);
//写入B的发件箱
//聚合数据
select feedId from outbox where userId in (select userId from follower where fanId = "A") order by create_time desc
List<Long> uids = getFromGroup(groupId); //获取分组下的所有用户 Long<List<Long>> ids = new ArrayList<List<Long>>();
for(Long id : uids) {
ids.add(getOutboxByUid(id)); //获取发件箱的内容id列表
}
return merge(ids); //合并排序所有的id
-
优点：
-
拉模式彻底解决了推送延迟的问题，大 V 发微博的时候不再需要推送到粉丝的收件箱，自然就不存在延迟的问题了\
-
存储成本降低
-
功能扩展性更好了\
-
-
缺点
-
对数据聚合成本较高
- 缓存高热点数据
-
缓存带宽较高
- 部署多个缓存副本
-
\
2.推拉结合的方案是怎样的
-
方案的核心在于大 V 用户在发布微博的时候，不再推送到全量用户，而是只推送给活跃的用户\
-
关于大v 粉丝数超过 50 万就算作大 V
-
活跃粉丝 刷新过信息流、发布过微博、转发评论点赞过微博，关注过其他用户等等
-
活跃粉丝列表是定长的，如果活跃粉丝数量超过了长度，就把最先加入的粉丝从列表里剔除，这样可以保证推送的效率\
-
非活跃用户异步写入消息
-
\
3.课程小结
-
使用场景
-
小规模 推
-
中规模 推拉
- 只推送活跃用户
-
大规模 拉
- 只保存用户发送数，通过查询聚合
- 聚合成本较高
-
学完本门课程啦，撒花!!!
