Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

大型微博应用Feed系统浅析

3,608 views

Published on

Published in: Business, Technology
  • Be the first to comment

大型微博应用Feed系统浅析

  1. 1. 大型微博应用feed系统浅析bob/板子<br />
  2. 2. 什么是微博<br />大型?小型?<br />小型微博实现方案<br />推、拉<br />发表队列<br />分页<br />单条feed<br />新浪、腾讯猜想<br />微博 在切客<br />
  3. 3. 什么是微博<br />为了不让你感到受侮辱,不做解释了<br />
  4. 4. 小型、大型<br />大型、小型没有严格界限<br />我的应用算大型吗?<br />一两台机器,join搞不定的就算大型吧<br />有的应用今天是小型,明天是大型<br />有的应用注定就是小型<br />永远只根据自己的需要设计,过度设计会把自己陷入尴尬境地<br />不要见到大型就拍砖!要淡定!!<br />
  5. 5. 小型微博实现方式<br />Feed 表,User表,Relation表<br />1.Select * from feed,relation where feed.uid = relation.target_id and relation.uid = xxx<br />2. select target_id from relation where uid = xxx 查出 relation list,然后去feed表,通过 in (relation_list)取出结果<br />3. 还不够快?建立feed_index表,只存放feed_id,uid, 查出ID,去feed表找其他内容<br />4.还不够快?恭喜你,你的应用成“大型”了<br />
  6. 6. 推<br />用户1 发表记录一条<br />找出能看到用户1的所有用户(用户1的粉丝)<br />在 u_feed表(不一定是mysql哦)对于每个粉丝写入一条记录(u_feed根据uid分库表,uid为粉丝的id,单条记录表示某feed对于某uid可见)<br />添加/删除关注时,需要处理feed id<br />
  7. 7. 拉<br />用户1发表记录<br />u_feed表写入一条记录(uid为发表人id)<br />小型微博的实现方案即为拉,只是具体的实现需要更为巧妙<br />一次拉取请求,基本可拆分为:<br />取 attention uid list<br />每个uid取最新发表的page_size条feed id,然后合并排序<br />
  8. 8. 拉<br />以上方案听起来不可思议?<br />你知道有人关注了2000人,怎么拉?<br />在微博的世界,一个用户最多可关注2000用户<br />但是每个用户平均关注远小于2000<br />但是,通过一些巧妙设计,并非这样的关注2000人的用户每次拉取,都需要查询2000次<br />但是,即便真的需要查询2000次,也不是世界末日<br />但是。。<br />但是。。还是别用mongo db 吧<br />
  9. 9. 推、拉?<br />推:<br />优:<br />读压力小<br />缺:<br />明星用户发表feed 写压力巨大<br />实现逻辑复杂,如新关注一个人,新取消一个关注,都需要复杂逻辑支持<br />拉:<br />优:<br />发表面前,人人平等,写压力几乎没有<br />逻辑比较简单<br />缺:<br />读压力大,实时拉取feedlist,并发高时,似乎missiong impossible<br />
  10. 10. 那,到底是推还是拉?<br />新浪微博暂时应以推为主<br />腾讯微博应是拉的方式<br />切客目前也完成了从推到拉的转型<br />微博的特点是读固然多,写也不少<br />推、拉并不完全互斥,也可以通过一些巧妙的逻辑实现推、拉并用<br />没有完美的方案,只选合适你用的方案<br />
  11. 11. 发表队列<br />发表一条feed,通常需要复杂的逻辑支持,你确定当你系统有些延迟的时候,潘石屹愿意等待150秒,等待这条微博发布成功?<br />不确定的话,就加个队列吧<br />App只负责处理最简单的逻辑,重逻辑丢到处理队列异步处理<br />推荐:redis<br />
  12. 12. 分页<br />我们可以:<br />SELECT * FROM XXX WHERE …<br />LIMIT start,page_size;<br />需要数据:当前页,每页显示条目<br />优点:够传统<br />灵活(除了逐页翻动以外,还可以跳到任意页)<br />缺点:page较大时,查询吃力<br />页面数据变动快时(比如关注较多,或是在春晚时刻),翻页会有重复(下翻)或漏失(上翻)数据<br />
  13. 13. 分页<br />我们也可以:<br />SELECT * FROM XXX WHERE …<br /> AND create_time < .. And feed_id < ..<br />LIMIT 0,page_size;<br />需要数据:<br />最后一条(第一条)feed id,create_time,每页显示条目<br />优点:上一页两个缺点的很好补充<br />缺点:只能上翻 或是下翻 <br />
  14. 14. 分页<br />微博的特点:<br />大多数需求是只看最新,会往下翻几页,但不会太多,一般不需要直接去看第128页<br />在热点事件发生时,或是关注人较多时,也许你看完第一页,想看下一页,这一页的所有数据已经成了下一页<br />我们不关心第几页,只想看本条信息前的50条信息<br />所以我们选择第二种方式!<br />
  15. 15. 分页<br />不要臆想用户需求?<br />你确实需要有时候从第一页直接跳到第十页?<br />OK,我们新的方法,其实也可以提供这样的“时光穿越”,欢迎交流<br />
  16. 16. 单条feed<br />根据feed_id拆分库表<br />比如每个表限定存放数据1000万条,初期建库10个,每个库有表10个,10亿数据后再建100个表,具体拆分规则可根据自己的实际情况掌握<br />新的数据丢入内存<br />比如memcache?然后的工作就是努力提高缓存命中率吧<br />选择适当的粒度<br />不要所有数据都存入一条缓存<br />
  17. 17. 新浪、腾讯猜想<br />腾讯:<br />根据url的情况,以及可以拉出任意古老的下一页的情况来看,应是“拉”来实现的<br />
  18. 18. 新浪、腾讯猜想<br />新浪:<br />根据timyang的分享,以及一共只<br />提供10页数据查看的状况猜测,目前<br />新浪仍是以“推”为主<br />
  19. 19. 微博 在 切客(www.qieke.com)<br />Mongo db 还是建议不要大规模使用<br />Redis相对有些复杂,目前在切客用来支持队列<br />自主开发了一套基于b+ tree 的indexdb索引系统<br />目前feed系统采用全拉的方案实现<br />
  20. 20. 微博 在 切客(www.qieke.com)<br />我们正在变大<br />我们经历了 推 ->推拉结合 ->拉 的转变<br />我们还会改变<br />我们业务比微博更为复杂,还需要解决:<br />以地点为纬度,查看地点下的所有feed<br />查询附近的feed<br />查询附近的地点<br />。。。。<br /> 期待热爱挑战的您的加入 xiamingran@snda.com<br />
  21. 21. bob/板子/56378301<br />谢谢!<br />2011/4/10<br />

×