大型微博应用 FEED系统浅析BOB/ 板子

1. 什么是微博2. 大型？小型？3. 小型微博实现方案4. 推、拉5. 发表队列6. 分页7. 单条 feed8. 新浪、腾讯猜想9. 微博 在 切客

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

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

小型微博实现方式 Feed 表， User 表， Relation 表1.Select * from feed,relation where feed.uid =

relation.target_id and relation.uid = xxx2. select target_id from relation where uid =

xxx 查出 relation list ，然后去 feed 表，通过 in （ relation_list ）取出结果3. 还不够快？建立 feed_index 表，只存放

feed_id,uid, 查出 ID ，去 feed 表找其他内容4. 还不够快？恭喜你，你的应用成“大型”了

推 用户 1 发表记录一条 找出能看到用户 1 的所有用户（用户 1的粉丝） 在 u_feed 表（不一定是 mysql 哦）对于每个粉丝写入一条记录（ u_feed 根据

uid 分库表， uid 为粉丝的 id ，单条记录表示某 feed 对于某 uid 可见） 添加 / 删除关注时，需要处理 feed id

拉 用户 1 发表记录 u_feed 表写入一条记录（ uid 为发表人

id ） 小型微博的实现方案即为拉，只是具体的实现需要更为巧妙 一次拉取请求，基本可拆分为：

1. 取 attention uid list2. 每个 uid 取最新发表的 page_size 条 feed

id ，然后合并排序

拉 以上方案听起来不可思议？ 你知道有人关注了 2000 人，怎么拉？ 在微博的世界，一个用户最多可关注 2000 用户 但是每个用户平均关注远小于 2000 但是，通过一些巧妙设计，并非这样的关注

2000 人的用户每次拉取，都需要查询 2000 次 但是，即便真的需要查询 2000 次，也不是世界末日 但是。。 但是。。还是别用 mongo db 吧

推、拉？ 推：

优：○ 读压力小

缺：○ 明星用户发表 feed 写压力巨大○ 实现逻辑复杂，如新关注一个人，新取消一个关注，都需要复杂逻辑支持

拉：优：

○ 发表面前，人人平等，写压力几乎没有○ 逻辑比较简单

缺：○ 读压力大，实时拉取 feedlist ，并发高时，似乎 missiong

impossible

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

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

分页 我们可以：

SELECT * FROM XXX WHERE …LIMIT start,page_size;

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

分页 我们也可以：

SELECT * FROM XXX WHERE … AND create_time < .. And feed_id < ..

LIMIT 0,page_size;

需要数据：最后一条 (第一条 )feed id ， create_time ，每页显示条目优点：上一页两个缺点的很好补充缺点：只能上翻 或是下翻

分页 微博的特点：

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

所以我们选择第二种方式！

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

单条 feed根据 feed_id 拆分库表

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

新浪、腾讯猜想 腾讯：

根据 url 的情况，以及可以拉出任意古老的下一页的情况来看，应是“拉”来实现的

新浪、腾讯猜想 新浪：

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

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

微博 在 切客（www.qieke.com） 我们正在变大 我们经历了 推 →推拉结合 →拉 的转变 我们还会改变 我们业务比微博更为复杂，还需要解决：

以地点为纬度，查看地点下的所有 feed查询附近的 feed查询附近的地点。。。。 期待热爱挑战的您的加入

xiamingran@snda.com

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