More Related Content
Similar to 大型微博应用Feed系统浅析 (20)
More from thinkinlamp (20)
大型微博应用Feed系统浅析
- 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
- 8. 拉 以上方案听起来不可思议? 你知道有人关注了2000人,怎么拉? 在微博的世界,一个用户最多可关注2000用户 但是每个用户平均关注远小于2000 但是,通过一些巧妙设计,并非这样的关注2000人的用户每次拉取,都需要查询2000次 但是,即便真的需要查询2000次,也不是世界末日 但是。。 但是。。还是别用mongo db 吧
- 9. 推、拉? 推: 优: 读压力小 缺: 明星用户发表feed 写压力巨大 实现逻辑复杂,如新关注一个人,新取消一个关注,都需要复杂逻辑支持 拉: 优: 发表面前,人人平等,写压力几乎没有 逻辑比较简单 缺: 读压力大,实时拉取feedlist,并发高时,似乎missiong impossible
- 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,每页显示条目 优点:上一页两个缺点的很好补充 缺点:只能上翻 或是下翻
- 19. 微博 在 切客(www.qieke.com) Mongo db 还是建议不要大规模使用 Redis相对有些复杂,目前在切客用来支持队列 自主开发了一套基于b+ tree 的indexdb索引系统 目前feed系统采用全拉的方案实现
- 20. 微博 在 切客(www.qieke.com) 我们正在变大 我们经历了 推 ->推拉结合 ->拉 的转变 我们还会改变 我们业务比微博更为复杂,还需要解决: 以地点为纬度,查看地点下的所有feed 查询附近的feed 查询附近的地点 。。。。 期待热爱挑战的您的加入 xiamingran@snda.com