1 条评论
06 Jan 2013

基于Redis的Feed推送系统(一) - 整体设计思路

之前我们的Feed聚合是基于纯数据库IN查询, 条件多还要加上排序, 当数据超过1kw之后, 就开始有慢语句产生. 做了索引优化拆分成两条语句, 第一句只取id, 保证查询是index only, 然后再循环取单条feed. 尽管如此不久以后还是渐渐不行, 某些语句会扫描30w行, 大概在2s左右.于是开始构思如何模仿新浪微博的推送体系.找了很多blog都没有找到稍微是具体的实现细节,苦逼的只能自己半猜想半模拟了.

终于某天在梦中, 得到了粗略的思路.

再具体细化一些后的思路

分为推和拉两部分, 姑且称为Distributor和Aggregator.

用户初始化上线的时候, 第一次刷新动态列表, 此时inbox是空白的. 此时Aggregator负责动态聚合第一页数据返回, 同时online标志位标记为1, 当下触发Aggregator取20条x50页数据填充inbox, 同时Distributor开始对此用户推送新feed. 此情况只发生在 offline->online 状态切换的时候.

用户上线完成后只需要读取inbox的内容, Distributor负责持续向online用户推送.

online标志位缓存时间72小时, 同时inbox也保持一致的缓存ttl.

删除feed的情况由前端输出时过滤, 系统本身不处理. 一是此情况很少, 二是代价太高, 没有必要.

当发生关注/取消关注时, 同步将本人的online标志清除, 下一次用户刷新动态列表时会自动rebuild.


P.S. 该系统目前已经构建完成, 基于gearman+php+redis, 具体的实现细节之后再分篇阐述.

仅有一条评论

  1. 1

    其实建就是feed系统:推拉模式
    http://www.habadog.com/2011/12/29/weibo-feed-push-system/

添加新评论