设为首页 收藏本站
查看: 1829|回复: 0

[经验分享] [转]微博后台架构浅析——读扩散pull、写扩散push、混合模式(push+pull)——相关cache(redis,memcache)

[复制链接]

尚未签到

发表于 2015-7-22 03:45:38 | 显示全部楼层 |阅读模式
原文地址:http://blog.163.com/xychenbaihu@yeah/blog/static/1322296552013430114959121/

之前在网上看到关于Twitter、Sina以及腾讯微薄的一些实现技术,这个简单做个摘要。
1、读扩散还是写扩散?
inbox: 收件箱,你收到的消息,即你所关注的人发布的消息。
outbox: 发件箱,你发布的消息。
写扩散(Push)
该方式为每个用户维护一个订阅列表,记录该用户订阅的消息索引(一般为消息ID、类型、发表时间等一些元数据)。每当用户发布消息时,都会去更新其follower的订阅列表。
优点:读很轻。初始化时仅需要读取自己的inbox即可。
缺点:写很重。每发布一个消息,会导致大量的写操作。
注:一般来说,用户发布消息,并不会更新所有followers的订阅列表,仅更新在线followers即可。
读扩散(Pull)
该方式为每个用户维护一个发送列表,记录该用户所有发表过的消息索引。
优点:写很轻,节省空间。用户每发布一条消息,仅需更新自己的outbox。
缺点:读操作很重,计算量大。假设你收听了1k用户,则初始化时,需要从1k个用户的outbox拉取消息,然后计算获得最新的n条消息。
混合模式(Push+Pull)
  该方式既为读写扩散的结合,根据用户followers的数量来决定是读扩散还是写扩散。例如followers大于1k的,则使用读扩散,否则使用写扩散。
从目前现在网上的一些资料来看,Twitter是写扩散,腾讯微薄是读扩散,新浪微薄则是二者结合。
2、关于Cache
对于一个千万级甚至亿级用户的大型网站来说,合理使用Cache至关重要。
一个用户的核心数据由如下几个部分组成:inbox,outbox,关系链,消息内容。

  • inbox:主要缓存消息索引,仅为在线用户缓存,从Timyang的PPT来看,新浪微薄估计是使用redis的list或set实现。
  • outbox:缓存一定数量(例如200)条最近发表的消息。
  • 关系链:following相对于followers来说,缓存容易些,follower加载开销比较大,例如刘翔在腾讯微薄的听众超过1600万。
  • 消息内容:按内容年龄缓存;一般需要多份支持容灾;需要缓存xml,json,rss,atom等多种格式的缓存以供API使用。
以Twitter为例,其将Cache分为四类:Vector Cache,Row Cache,Page Cache,Fragment Cache,均使用memcached实现。其中:

  • Vector Cache主要缓存用户的inbox以及outbox索引,其命中率高达99%;
  • Row Cache主要缓存用户关系链数据,以及Tweets内容,命中率为95%;
  • Fragment Cache缓存Tweet的xml,json,rss,atom四种格式数据,以供API使用,命中率为95%;
  • Page Cache主要原来缓存那些高人气用户的个人主页,命中率仅为40%。
下图为TwitterCache架构图:
DSC0000.jpg
Twitter为啥要为API通道设置Fragment Cache和Page Cahce呢?其原因是Twitter的80%流量来自API。
下面以新浪微薄介绍一下Cache流程:
消息发布流程:

  • 更新自己的outbox
  • 加载followers列表
  • 更新followers inbox
获取首页流程:

  • 检查inbox cache是否可用
  • 获取关注列表
  • 聚合内容,获得消息索引
  • 根据索引,返回最终聚合的消息内容
3、关于存储
目前Twitter和新浪的落地存储,都是使用MySQL。而腾讯微薄则使用采用SSD+大文件存储(每次写操作都是append操作,写操作可以先用内存缓存,达到适当大小合并,尽量减少随机写)。其他细节因不清楚或不方便透露,不做细述。
4、关于洪峰处理。
一般用异步队列处理方式。消息队列产品有:Kestrel(twitter使用Scala实现),RabbitMQ(使用Erlang实现),MemcacheQ。
Twitter 09年时,用户的平均followers数量为126个。按照每秒400消息发布数算,那每秒就需要推送126*400=50400条消息出去。为了削峰,Twitter自己用Scala实现了一个分布式消息队列Kestrel,其代码仅为1200行,运行在3台机器上,其使用memcached协议,其Server之间无共享状态,且全内存。新浪使用的是MemcacheQ。

参考文献:

    • 构建可扩展的微薄架构,by TimYang
    • Twitter, An Evolving Architecture,by Abel Avrami
    • 微薄Cache设计谈,by Timyang
    • Improve Running Components at Twitter (PDF slide), by Evan Weaver
    • 解剖Twitter系列,by 邓侃


运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-89176-1-1.html 上篇帖子: 【redis源码】(九)Redis 下篇帖子: CentOS 下 Redis 安装
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表