加载中 ...
首页 > 新闻资讯 > 经验心得 正文

微博CacheService架构浅析

2019-03-23 07:30:26 来源:沈阳软件公司 作者:沈阳软件开发

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

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

Cache的伸缩容和节点的替换消息太大

对于微博这种会在热门事务、节沐日等发生时会有一些失常峰值(往往是数倍或者数十倍)的场景而言,实时的动态伸缩容很是须要,而由于通过client端实例化的Memcached资源节点相对比力牢固,因此要举行伸缩容需要:

    举行一次代码的线上变换,举行节点设置的变换,而若是依赖该某组资源的应用系统比力多,好比底层的认证资源,那么需要对多个营业系统变换,这一消息不行谓不小,特殊是遇到紧迫情形,这个会导致操作的执行很缓慢。需要解决读写导致的一致性问题,如果有一些营业系统在读取Cache,有一些营业系统在写入Cache,而正常的变换是比力难让这些系统在某一刻所有执行节点的设置切换。需要使用新的节点替换老的节点(好比替换物理机),面临和上面类似的问题。

过多资源带来的运维问题

  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的响应返回给营业挪用端。

“沈阳软件公司”的新闻页面文章、图片、音频、视频等稿件均为自媒体人、第三方机构发布或转载。如稿件涉及版权等问题,请与

我们联系删除或处理,客服QQ:55506560,稿件内容仅为传递更多信息之目的,不代表本网观点,亦不代表本网站赞同

其观点或证实其内容的真实性。