• Feeds

  • Posts Tagged ‘weibo’


    基于分发机制的公众订阅平台设计


    如下图所示,一个基于分发机制的公众订阅平台,是指一个移动信息发布系统,可提供订阅功能的系统企业帐号可以给所有的订阅用户按照一定的条件(如地域或用户特征)群发消息,系统的主要关注点包括

    • 分发的throughput。由于群发的放大效应,如何让拥有大量订阅用户的企业帐号能及时投递消息。以及到客户端的移动push通道也存在throughput的问题。
    • 存储的性能,根据客户端的访问型态,如果考虑数据保存在云端,大多需要更新最近联系人、用户与企业订阅帐号之间的会话索引,以及每个会话的未读提醒数。由于客户端本地也可以保存部分数据,因此不同的实现型态可能云端存储及更新的数据有一定差异。
    • 分发及存储模型。分发指数据投递推拉方式的选取,由于筛选条件及通过移动网络主动push的可能性,推送方式可以更好满足业务型态。存储模型指如何选择合适的模型让上万订阅用户的推送能更及时快捷。

    (图中紫色为可能的瓶颈点)

    从图来看,实现并不复杂,但是当系统规模增大之后,如要达到投递即时性需要考验一些工程能力。
    紫色的三个框都可以用key/list来表达,redis的性能和功能可以匹配这样一个场景,这也是为什么近几年redis会如此流行,但离完美匹配类似场景还有一定距离。

    Notes about Timelines @ Twitter

    Twitter timeline团队负责人在QCon London上分享了一篇Timelines @ Twitter的演讲,以下是其中一些摘要。

    数据

    1亿活跃用户
    Timeline接口2万QPS
    推送平均1ms,99% 4ms以内
    每天2.5亿条新Tweets,平均3千/秒,峰值1万以上。
    每天260亿次分发,每秒1800万(从中看出平均关注100人)
    投递100万粉丝的时间需要3.5秒,每秒可投递28万

    架构

    材料中以介绍推(fan-out)为主
    对于followers多的用户,从fan-out上采用pipeline的方式并行投递推送,每个任务负责分发4000个粉丝

    fan-out首先投递到timeline cache上(page cache?)
    用户收件箱采用redis存储,Redis只包括活跃用户,冷用户随时间过期
    使用Redis的list数据结构,每个item中还包括tweet ID, user ID及标志位3个字段
    使用Redis RPUSHX来避免写入冷用户
    对于频繁访问用户的timeline, 设置in-process cache(local cache)
    fan-out及fan-in的比较如下

    技术选型与演进

    Redis,使用了Redis来代替之前的memcached来存储vector cache
    Thrift, 内部调用已经基本使用Thrift方式服务化,参看P109
    Scala,内部服务基本使用Scala实现,但搜索模块使用Java实现,视频Q&A中提到
    Finagle,较多篇幅介绍,是一个Scala实现的网络库,基于Netty框架的基础上

    构建高性能的微博系统(QCon Beijing 2011演讲)

    提示:

    • QCon网站提供此演讲下载的PDF是老版,大约有30%的内容改变,已经通知Update
    • Slideshare文档在对方网站可浏览及下载,但是下载只提供Mac OS Keynote格式,PDF格式太大未提供(上传转换1小时未完成),有需要可以到QCon Beijing官网下载
    12