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 = xxx2. 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

关键字:大型 微博 应用 feed 系统 浅析 | 来源:互联网 | 责任编辑:系统管理员 | 最后编辑:2012年02月01日 14时27分26秒