, 一次性获取固定条数(这里 以20为例)的微博, 到达底部后继续刷新按照时间顺序显示后续20条博客, 其他功能转发, 评论, 收藏, 点赞这里不做讨论性能指标估计 系统按10亿用户设计,按20%...相当于设计了设计了一个三级缓存(CDN缓存, NGINX缓存, Redis缓存), 来避免大量查询走数据库Post链路分析 当用户发布一篇博客时, 不需要走CDN缓存, 直接通过负载均衡到应用服务器上..., 再由消费者程序从消息队列中按照一定的速度来消费消息, 并写入数据库, 保证数据库的负载压力不会突然增加详细设计 关于发表, 订阅问题 当用户关注好友后, 如何快速得到所有好友的最新发表的博客内容...也就是Feed流该如何设计,这里我们详细展开讲一下 拉模式 一部分工程师认为应该在查询时首先查询用户关注的所有创作者 uid,然后查询他们发布的所有文章,最后按照发布时间降序排列 使用拉模型方案用户每打开一次...对于用户来说并不友好推模式 另一部分工程师认为在创作者发布文章时就应该将新文章写入到粉丝的关注 Timeline,用户每次阅读只需要到自己的关注 Timeline 拉取就可以了 使用推模型方案创作者每次发布新文章系统就需要写入