1. 大型微博应用feed系统浅析bob/板子

2. 什么是微博 大型？小型？ 小型微博实现方案 推、拉 发表队列 分页 单条feed 新浪、腾讯猜想 微博 在切客

3. 什么是微博 为了不让你感到受侮辱，不做解释了

4. 小型、大型 大型、小型没有严格界限 我的应用算大型吗? 一两台机器，join搞不定的就算大型吧 有的应用今天是小型，明天是大型 有的应用注定就是小型 永远只根据自己的需要设计，过度设计会把自己陷入尴尬境地 不要见到大型就拍砖！要淡定！！

5. 小型微博实现方式 Feed 表，User表，Relation表 1.Select * from feed,relation where feed.uid = relation.target_id and relation.uid = xxx 2. select target_id from relation where uid = xxx 查出 relation list，然后去feed表，通过 in （relation_list）取出结果 3. 还不够快？建立feed_index表，只存放feed_id,uid, 查出ID，去feed表找其他内容 4.还不够快？恭喜你，你的应用成“大型”了

6. 推 用户1 发表记录一条 找出能看到用户1的所有用户（用户1的粉丝） 在 u_feed表（不一定是mysql哦）对于每个粉丝写入一条记录（u_feed根据uid分库表，uid为粉丝的id，单条记录表示某feed对于某uid可见） 添加/删除关注时，需要处理feed id

7. 拉 用户1发表记录 u_feed表写入一条记录（uid为发表人id） 小型微博的实现方案即为拉，只是具体的实现需要更为巧妙 一次拉取请求，基本可拆分为： 取 attention uid list 每个uid取最新发表的page_size条feed id，然后合并排序

8. 拉 以上方案听起来不可思议？ 你知道有人关注了2000人，怎么拉？ 在微博的世界，一个用户最多可关注2000用户 但是每个用户平均关注远小于2000 但是，通过一些巧妙设计，并非这样的关注2000人的用户每次拉取，都需要查询2000次 但是，即便真的需要查询2000次，也不是世界末日 但是。。 但是。。还是别用mongo db 吧

9. 推、拉？ 推： 优： 读压力小 缺： 明星用户发表feed 写压力巨大 实现逻辑复杂，如新关注一个人，新取消一个关注，都需要复杂逻辑支持 拉： 优： 发表面前，人人平等，写压力几乎没有 逻辑比较简单 缺： 读压力大，实时拉取feedlist，并发高时，似乎missiong impossible

10. 那，到底是推还是拉？ 新浪微博暂时应以推为主 腾讯微博应是拉的方式 切客目前也完成了从推到拉的转型 微博的特点是读固然多，写也不少 推、拉并不完全互斥，也可以通过一些巧妙的逻辑实现推、拉并用 没有完美的方案，只选合适你用的方案

11. 发表队列 发表一条feed，通常需要复杂的逻辑支持，你确定当你系统有些延迟的时候，潘石屹愿意等待150秒，等待这条微博发布成功？ 不确定的话，就加个队列吧 App只负责处理最简单的逻辑，重逻辑丢到处理队列异步处理 推荐：redis

12. 分页 我们可以： SELECT * FROM XXX WHERE … LIMIT start,page_size; 需要数据：当前页，每页显示条目 优点：够传统 灵活（除了逐页翻动以外，还可以跳到任意页） 缺点：page较大时，查询吃力 页面数据变动快时(比如关注较多，或是在春晚时刻)，翻页会有重复（下翻）或漏失（上翻）数据

13. 分页 我们也可以： SELECT * FROM XXX WHERE … AND create_time < .. And feed_id < .. LIMIT 0,page_size; 需要数据： 最后一条(第一条)feed id，create_time，每页显示条目 优点：上一页两个缺点的很好补充 缺点：只能上翻 或是下翻

14. 分页 微博的特点： 大多数需求是只看最新，会往下翻几页，但不会太多，一般不需要直接去看第128页 在热点事件发生时，或是关注人较多时，也许你看完第一页，想看下一页，这一页的所有数据已经成了下一页 我们不关心第几页，只想看本条信息前的50条信息 所以我们选择第二种方式！

15. 分页 不要臆想用户需求？ 你确实需要有时候从第一页直接跳到第十页？ OK，我们新的方法，其实也可以提供这样的“时光穿越”,欢迎交流

16. 单条feed 根据feed_id拆分库表 比如每个表限定存放数据1000万条，初期建库10个，每个库有表10个，10亿数据后再建100个表，具体拆分规则可根据自己的实际情况掌握 新的数据丢入内存 比如memcache？然后的工作就是努力提高缓存命中率吧 选择适当的粒度 不要所有数据都存入一条缓存

17. 新浪、腾讯猜想 腾讯： 根据url的情况，以及可以拉出任意古老的下一页的情况来看，应是“拉”来实现的

18. 新浪、腾讯猜想 新浪： 根据timyang的分享，以及一共只 提供10页数据查看的状况猜测，目前 新浪仍是以“推”为主

19. 微博 在 切客（www.qieke.com） Mongo db 还是建议不要大规模使用 Redis相对有些复杂，目前在切客用来支持队列 自主开发了一套基于b+ tree 的indexdb索引系统 目前feed系统采用全拉的方案实现

20. 微博 在 切客（www.qieke.com） 我们正在变大 我们经历了 推 ->推拉结合 ->拉 的转变 我们还会改变 我们业务比微博更为复杂，还需要解决： 以地点为纬度，查看地点下的所有feed 查询附近的feed 查询附近的地点 。。。。 期待热爱挑战的您的加入 xiamingran@snda.com

21. bob/板子/56378301 谢谢！ 2011/4/10