Your SlideShare is downloading. ×
0
大型微博应用feed系统浅析bob/板子<br />
什么是微博<br />大型?小型?<br />小型微博实现方案<br />推、拉<br />发表队列<br />分页<br />单条feed<br />新浪、腾讯猜想<br />微博 在切客<br />
什么是微博<br />为了不让你感到受侮辱,不做解释了<br />
小型、大型<br />大型、小型没有严格界限<br />我的应用算大型吗?<br />一两台机器,join搞不定的就算大型吧<br />有的应用今天是小型,明天是大型<br />有的应用注定就是小型<br />永远只根据自己的需要设计,过度设计...
小型微博实现方式<br />Feed 表,User表,Relation表<br />1.Select * from feed,relation where feed.uid = relation.target_id and relation.u...
推<br />用户1 发表记录一条<br />找出能看到用户1的所有用户(用户1的粉丝)<br />在 u_feed表(不一定是mysql哦)对于每个粉丝写入一条记录(u_feed根据uid分库表,uid为粉丝的id,单条记录表示某feed对于...
拉<br />用户1发表记录<br />u_feed表写入一条记录(uid为发表人id)<br />小型微博的实现方案即为拉,只是具体的实现需要更为巧妙<br />一次拉取请求,基本可拆分为:<br />取 attention uid list...
拉<br />以上方案听起来不可思议?<br />你知道有人关注了2000人,怎么拉?<br />在微博的世界,一个用户最多可关注2000用户<br />但是每个用户平均关注远小于2000<br />但是,通过一些巧妙设计,并非这样的关注200...
推、拉?<br />推:<br />优:<br />读压力小<br />缺:<br />明星用户发表feed 写压力巨大<br />实现逻辑复杂,如新关注一个人,新取消一个关注,都需要复杂逻辑支持<br />拉:<br />优:<br />发表...
那,到底是推还是拉?<br />新浪微博暂时应以推为主<br />腾讯微博应是拉的方式<br />切客目前也完成了从推到拉的转型<br />微博的特点是读固然多,写也不少<br />推、拉并不完全互斥,也可以通过一些巧妙的逻辑实现推、拉并用<b...
发表队列<br />发表一条feed,通常需要复杂的逻辑支持,你确定当你系统有些延迟的时候,潘石屹愿意等待150秒,等待这条微博发布成功?<br />不确定的话,就加个队列吧<br />App只负责处理最简单的逻辑,重逻辑丢到处理队列异步处理<...
分页<br />我们可以:<br />SELECT * FROM XXX WHERE …<br />LIMIT  start,page_size;<br />需要数据:当前页,每页显示条目<br />优点:够传统<br />灵活(除了逐页翻动以...
分页<br />我们也可以:<br />SELECT * FROM XXX WHERE …<br />		  AND create_time < .. And feed_id < ..<br />LIMIT  0,page_size;<br /...
分页<br />微博的特点:<br />大多数需求是只看最新,会往下翻几页,但不会太多,一般不需要直接去看第128页<br />在热点事件发生时,或是关注人较多时,也许你看完第一页,想看下一页,这一页的所有数据已经成了下一页<br />我们不关...
分页<br />不要臆想用户需求?<br />你确实需要有时候从第一页直接跳到第十页?<br />OK,我们新的方法,其实也可以提供这样的“时光穿越”,欢迎交流<br />
单条feed<br />根据feed_id拆分库表<br />比如每个表限定存放数据1000万条,初期建库10个,每个库有表10个,10亿数据后再建100个表,具体拆分规则可根据自己的实际情况掌握<br />新的数据丢入内存<br />比如me...
新浪、腾讯猜想<br />腾讯:<br />根据url的情况,以及可以拉出任意古老的下一页的情况来看,应是“拉”来实现的<br />
新浪、腾讯猜想<br />新浪:<br />根据timyang的分享,以及一共只<br />提供10页数据查看的状况猜测,目前<br />新浪仍是以“推”为主<br />
微博 在 切客(www.qieke.com)<br />Mongo db 还是建议不要大规模使用<br />Redis相对有些复杂,目前在切客用来支持队列<br />自主开发了一套基于b+ tree 的indexdb索引系统<br />目前fe...
微博 在 切客(www.qieke.com)<br />我们正在变大<br />我们经历了 推 ->推拉结合 ->拉 的转变<br />我们还会改变<br />我们业务比微博更为复杂,还需要解决:<br />以地点为纬度,查看地点下的所有fee...
bob/板子/56378301<br />谢谢!<br />2011/4/10<br />
Upcoming SlideShare
Loading in...5
×

大型微博应用Feed系统浅析

3,058

Published on

Published in: Business, Technology
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,058
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
94
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

Transcript of "大型微博应用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 />
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×