大型微博应用Feed系统浅析【转】

大型微博应用Feed系统浅析 - Presentation Transcript
大型微博应用feed系统浅析bob/板子

什么是微博
大型？小型？
小型微博实现方案
推、拉
发表队列
分页
单条feed
新浪、腾讯猜想
微博 在切客

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

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

小型微博实现方式
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.还不够快？恭喜你，你的应用成“大型”了

推
用户1 发表记录一条
找出能看到用户1的所有用户（用户1的粉丝）
在 u_feed表（不一定是mysql哦）对于每个粉丝写入一条记录（u_feed根据uid分库表，uid为粉丝的id，单条记录表示某feed对于某uid可见）
添加/删除关注时，需要处理feed id

拉
用户1发表记录
u_feed表写入一条记录（uid为发表人id）
小型微博的实现方案即为拉，只是具体的实现需要更为巧妙
一次拉取请求，基本可拆分为：
取 attention uid list
每个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