微博CacheService架构浅析

标签: 微博 cacheservice 架构 | 发表时间:2014-04-26 10:14 | 作者:
出处:http://kb.cnblogs.com/

  微博作为国内最大的社交媒体网站之一,每天承载着亿万用户的服务请求,这些请求的背后,需要消耗着巨大的计算、内存、网络、I/O等资源。而且因为微博的产品特性,节假日、热门事件等可能带来突发数倍甚至十几倍的访问峰值,这些都对于支撑微博的底层基础架构提出了比较严苛的要求,需要满足:

  1. 每秒数十万的用户请求
  2. 数据更新的实时性
  3. 服务请求的低响应时间
  4. 99. 99%以上的服务可用性

  为了满足业务的发展需要,微博平台开发了一套高性能高可用的CacheService架构用于支撑现有线上的业务系统的运转。但“冰动三尺非一日之寒”,微博的Cache架构也是经历了从无到有,不断的演进过程。

   基于MySQL的Web架构

  最初的微博系统,系统的访问量都比较小,简单的基于数据库(MySQL)已经能够满足业务需求,开发也比较简单,简单的架构示意图如下:

  随着微博的推广和名人用户入驻微博,带动了用户量的快速增长,访问量也与日俱增,这个时候,简单基于MySQL的架构已经略感吃力,系统响应也比较缓慢,因为MySQL是一个持久化存储的解决方案,数据的读写都会经过磁盘,虽然MySQL也有buffer pool,但是无法根据业务的特性做到很细粒度的控制,而在微博这种业务场景下,配置了SAS盘的MySQL服务单机只能支撑几千的请求量,远小于微博的业务请求量。

   基于单层Cache+MySQL的Web架构

  针对请求量增大的问题,一般有几种解决方案:

  1. 业务架构改造,但是在这种场景下,这种方案的可行性不高。
  2. MySQL进行从库扩容,虽然能够解决问题,但是带来的成本也会比较高,而且即使能够抗住请求量,但是资源的响应时间还是无法满足期望的结果,因为磁盘的读取的响应时间要相对比较慢,普通的15000转/分钟的SAS盘的读取延迟平均要达到2ms以上。
  3. 在MySQL之上架构一层缓存,把热门请求数据缓存到Cache,基于Cache+MySQL的架构来提供服务请求。

  考虑到整体的改动和成本的因素,基于方案3)比较适合微博的业务场景。而应该使用什么类型的Cache比较合适呢?

  比较常见的Cache解决方案有:

  1. Local Cache,通过在Web应用端内嵌一个本地的Cache,这种的优势是访问比较快,但是存在的问题也比较明显,数据更新的一致性比较难保证,因此使用的范围会有一定的限制。
  2. 单机版的远程Cache,通过部署一套远程的Cache服务,然后应用端请求通过网络请求与Cache交互,为了解决应用的水平扩展和容灾问题,往往通过在client层面来实现数据的路由等。
  3. 分布式的Cache,Cache服务本身是一个大集群,能够提供给各种业务应用使用,并提供了一些基本的分布式特性:水平扩展、容灾、数据一致性等等。

  从系统的简单性考虑和微博场景的适用问题,最终选择了2)的方式,基于开源的Memcached来作为微博的Cache方案。

  Memcached是一个分布式Cache Server,提供了key-value型数据的缓存,支持LRU、数据过期淘汰,基于Slab的方式管理内存块,提供简单的set/get/delete等操作协议,本身具备了稳定、高性能等优点,并在业界已经得到广泛的验证。它的server端本身是一个单机版,而分布式特性是基于client端的实现来满足,通过部署多个Memcached节点,在client端基于一致性hash(或者其他hash策略)进行数据的分散路由,定位到具体的memcached节点再进行数据的交互。当某个节点挂掉后,对该节点进行摘除,并把该节点的请求分散到其他的节点。通过client来实现一定程度的容灾和伸缩的能力。

  这种架构经过一段时间的蜜月期后,也逐步遇到了一些问题。

  • 节点挂掉导致的瞬间的峰值问题

    比如部署有5个Memcached节点,对key做一致性hash将key散落分布到5个节点上,那么如果其中有1个节点挂掉,那么这个时候会有20%原本Cache hit的请求穿透到后端资源(比如DB)。对于微博而言,多数核心资源的Cache hit的比例是99%,单组资源的QPS可能就达到100W以上的级别,如果这个时候有20%的穿透,那么相当于后端资源需要抗住20W以上的请求,这对于后端资源来说,明显压力过大。

  • 某组资源请求量过大导致需要过多的节点

    微博的Feed业务是Cache资源的消耗大户,几十万的QPS,GB(Byte)级别以上的带宽消耗,这个时候,至少需要十几个Memcached节点单元才能够抗住请求,而过多的Memcached节点请求会导致multiget的性能有弱化,因为这个时候keys分散到的Memcached节点会比较多,因此当进行拉取聚合的时候,性能会受影响,同时mutliget的响应时间受最慢的那个节点的影响,从而无法达到服务的SLA要求。

  • Cache的伸缩容和节点的替换动静太大

      对于微博这种会在热点事件、节假日等发生时会有一些变态峰值(往往是数倍或者数十倍)的场景而言,实时的动态伸缩容很是必要,而因为通过client端实例化的Memcached资源节点相对比较固定,因此要进行伸缩容需要:

    1. 进行一次代码的线上变更,进行节点配置的变更,而如果依赖该某组资源的应用系统比较多,比如底层的认证资源,那么需要对多个业务系统变更,这一动静不可谓不小,特别是遇到紧急情况,这个会导致操作的执行很缓慢。
    2. 需要解决读写导致的一致性问题,假如有一些业务系统在读取Cache,有一些业务系统在写入Cache,而正常的变更是比较难让这些系统在某一刻全部执行节点的配置切换。
    3. 需要使用新的节点替换老的节点(比如更换物理机),面临和上面类似的问题。
  • 过多资源带来的运维问题

  Cache资源组是按业务去申请,当业务特别多的时候,Cache资源组也会很多,这个时候要对这些资源进行运维管理如调整,将会变得不容易。而且随着时间的演进,一些比较古老的资源年老失修的情况,要进行运维调整就更为不容易。

  • Cache架构要用得好的复杂度

  会用和用得好是两个不同概念。如果Cache架构需要每个业务开发很熟练才能够用得好,而不会因为Cache的不当使用而导致线上服务出现稳定性问题、以及成本的浪费等各种问题的话,这种对于需要陆续补进新人的团队现状而言,出问题将会是一种常态。 因此要解决这种问题,那么需要提供一种足够简单的Cache使用方式给业务应用方,简单到只有set/get/delete等基本命令的操作,而无需要他们关心底层的任何细节。

   分布式CacheService架构

  为了解决这些问题,微博的Cache服务架构进行了演进,通过把Cache服务化,提供一个分布式的CacheService架构,简化业务开发方的使用,实现系统的动态伸缩容、容灾、多层Cache等相关功能。

  CacheService架构示意图如下:

  系统由几个模块组成:

  • ConfigService

    这一模块是基于现有微博的配置服务中心,它主要是管理静态配置和动态命名服务的一个远程服务,能够在配置发生变更的时候实时通知监听的config client。

  • proxy层

    这一模块是作为独立的应用对外提供代理服务,用来接收来自业务端的请求,并基于路由规则转发到后端的Cache资源,它本身是无状态的节点。它包含了如下部分:

  • 异步事件处理(event handler): 用来管理连接、接收数据请求、回写响应。
  • Processor: 用来对请求的数据进行解析和处理。
  • Adapter:用来对底层协议进行适配,比如支持MC协议,Redis协议。
  • Router: 用来对请求进行路由分发,分发到对应的Cache资源池,进而隔离不同业务。
  • LRU Cache: 用来优化性能,缓解因为经过proxy多一跳(网络请求)而带来的性能弱化。
  • Timer: 用来执行一些后端的任务,包含对底层Cache资源健康状态的探测等。

  Proxy启动后会去从config Service加载后端Cache资源的配置列表进行初始化,并接收configService的配置变更的实时通知。

  • Cache资源池

    这一模块是作为实际数据缓存的模块,通过多层结构来满足服务的高可用。 其中Main-node是主缓存节点,Ha-Node是备份节点,当Main-node挂掉后,数据还能够从Ha-Node节点获取避免穿透到后端资源,L1-node主要用来抗住热点的访问,它的容量一般比Main-node要小,其中L1-node可支持多组,方便进行水平扩容以支撑更高的吞吐。

  • Client客户端

    这一模块主要是提供给业务开发方使用的client(sdk包),对外屏蔽掉了所有细节,只提供了最简单的get/set/delete等协议接口,从而简化了业务开发方的使用。

    应用启动时,Client基于namespace从configService中获取相应的proxy节点列表,并建立与后端proxy的连接。正常一个协议处理,比如set命令,client会基于负载均衡策略挑选当前最小负载的proxy节点,发起set请求,并接收proxy的响应返回给业务调用端。

    Client会识别configService推送的proxy节点变更的情况重建proxy连接列表,同时client端也会做一些容灾,在proxy节点出现问题的时候,把proxy进行摘除,并定期探测是否恢复。

  目前微博平台部分业务子系统的Cache服务已经迁移到了CacheService之上,它在实际的运行过程中也取得了良好的性能表现,目前整个集群在线上每天支撑着超过300W的QPS,平均响应耗时低于1ms。

  它本身具备了以下特性:

  • 高可用保证

    所有的数据写入请求,CacheService会把数据双写到ha的节点,这样,在main-node挂掉的时候,会从ha-node读取数据,从而防止节点fail的时候给后端资源(DB等)带来过大的压力。

  • 服务的水平扩展

    CacheService proxy节点本身是无状态的,在proxy集群存在性能问题的时候,能够简单的通过增减节点来伸缩容。而对于后端的Cache资源,通过增减L1层的Cache资源组,来分摊对于main-node的请求压力。这样多数热点数据的请求都会落L1层,而L1层可以方便的通过增减Cache资源组来进行伸缩容。

  • 实时的运维变更

    通过整合内部的config Service系统,能够在秒级别做到资源的扩容、节点的替换等相关的运维变更。

  • 跨机房特性:

    微博系统会进行多机房部署,跨机房的服务器网络时延和丢包率要远高于同机房,比如微博广州机房到北京机房需要40ms以上的时延。CacheService进行了跨机房部署,对于Cache的查询请求会采用就近访问的原则,对于Cache的更新请求支持多机房的同步更新。

  目前微博的分布式CacheService架构在简化了业务开发使用的同时,提高了系统的可运维性和可用性。接下来的架构的改造方向是提供后端Cache资源的低成本解决方案,从单机的存储容量和单机的极限性能层面不断优化。因为对于微博的业务场景,冷热数据相对比较明显,同时长尾数据请求的比例也不小,因而如果减少了Cache的容量,那么会导致后端资源无法抗住请求,而扩大Cache的容量,又会导致成本的浪费。而全内存的解决方案相比而言成本相对比较高,所以热数据存放到内存,基于LRU的策略把冷数据交换到固体硬盘(SSD),这是一种可能选择的方向。

相关 [微博 cacheservice 架构] 推荐:

微博CacheService架构浅析

- - 博客园_知识库
  微博作为国内最大的社交媒体网站之一,每天承载着亿万用户的服务请求,这些请求的背后,需要消耗着巨大的计算、内存、网络、I/O等资源. 而且因为微博的产品特性,节假日、热门事件等可能带来突发数倍甚至十几倍的访问峰值,这些都对于支撑微博的底层基础架构提出了比较严苛的要求,需要满足:.   为了满足业务的发展需要,微博平台开发了一套高性能高可用的CacheService架构用于支撑现有线上的业务系统的运转.

新浪微博图床架构解析

- - CSDN博客架构设计推荐文章
可以先看一下  http://c.blog.sina.com.cn/profile.php?blogid=a466bf9189000rsw 新浪微博官方发出来的文章. 以下我们来解析一下如何构建高可用的图片存储系统 以满足现在日益增长的图片量,保证系统稳定高效的运行. 图床系统 ,我们先来分析下基于此类系统的一个特性.

微博推荐架构的演进

- - ITeye资讯频道
微博(Weibo)是一种通过关注机制分享简短实时信息的广播式社交网络平台. 微博用户通过关注来订阅内容,在这种场景下,推荐系统可以很好地和订阅分发体系进行融合,相互促进. 微博两个核心基础点:一是用户关系构建,二是内容传播,微博推荐一直致力于优化这两点,促进微博发展. 在微博推荐发展的过程中遇到体系方向的变化、业务的不断更迭、目标的重新树立,其产品思路、架构以及算法也随之进行变迁.

microblogging和微博信息架构产品差距和影响

- cgeek - demo@virushuo
前一段时间仔细的把国内的微博产品都研究了一圈. 这个话题说起来很复杂,我从信息架构开始说,后面涉及传播方式,社群,阅读负担和信息过滤,第三方和开放性几个方面. 最后会使用我blog这几年的访问数据对新浪微博和twitter传播能力做一个简要分析. 以下除特指某一家的产品,我用国内微博代表国内除饭否之外所有其他微博,因为他们产品都很相似.

微博架构与平台安全演讲稿

- Class4 - Tim[后端技术]
本文是在2010中国首届微博开发者大会演讲稿(PPT),由于网上已经有演讲视频及全程文字记录,这里就不做补充,演讲稿如下. 微博架构与平台安全 View more presentations from Tim Y.. 需要下载请点击 view on Slideshare,在 Slideshare 打开后 Download.

新浪微博技术架构分析-转载

- 盛开 - 人月神话的BLOG
中国首届微博开发者大会在北京举行,这是国内微博行业的首场技术盛宴. 作为国内微博市场的绝对领军者,新浪微博将在此次大会上公布一系列针对开发者的扶持政策,以期与第三方开发者联手推动微博行业的整体发展. 图为微博平台首席架构师杨卫华演讲. 大家下午好,在座的大部分都是技术开发者,技术开发者往往对微博这个产品非常关心.

[转]新浪微博的架构发展历程

- - 小彰
新浪科技讯 11月16日下午消息,由 新浪微博( http://t.sina.com.cn)( http://t.sina.com.cn)主办的中国首届微博开发者大会在北京举行,这是国内微博行业的首场技术盛宴. 作为国内微博市场的绝对领军者,新浪微博将在此次大会上公布一系列针对开发者的扶持政策,以期与第三方开发者联手推动微博行业的整体发展.

亿级用户下的新浪微博平台架构

- - 博客园_知识库
  新浪微博在2014年3月公布的月活跃用户(MAU)已经达到1.43亿,2014年新年第一分钟发送的微博达808298条,如此巨大的用户规模和业务量,需要高可用(HA)、高并发访问、低延时的强大后台系统支撑.   微博平台第一代架构为LAMP架构,数据库使用的是MyIsam,后台用的是php,缓存为Memcache.

微博feed系统的推(push)模式和拉(pull)模式和时间分区拉模式架构探讨

- 荷泽 - 博客园-草屋主人的blog
微博feed系统的推(push)模式和拉(pull)模式和时间分区拉模式架构探讨.      [文章作者:孙立 链接:http://www.cnblogs.com/sunli/ 更新时间:2010-08-24].      sns系统,微博系统都应用到了feed(每条微博或者sns里的新鲜事等我们称作feed)系统,不管是twitter.com或者国内的新浪微博,人人网等,在各种技术社区,技术大会上都在分享自己的feed架构,也就是推拉模式(timyang上次也分享了新浪微薄的模式).

新浪微博混合云架构实践挑战之容器编排设计与实践

- - IT瘾-tuicool
《微博混合云架构》专栏是InfoQ向新浪微博技术团队的系列约稿,本专栏包含8篇内容,详细阐述以DCP设计理念为指导思想的混合云架构实践. 本文是该系列的第五篇,主要介绍容器编排的设计与实现. 《微博混合云架构》专栏主要包括以下8篇内容:. DCP的容器编排设计与实践. 最近由于个人原因,与InfoQ约稿的专栏《微博混合云架构》很久没更新了,在此深表歉意.