微博CacheService架构浅析
2019-03-23 07:30:26 来源：沈阳软件公司 作者：沈阳软件开发
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的更新请求支持多机房的同步更新app开发。
现在微博的漫衍式CacheService架构在简化了营业开发使用的同时，提高了系统的可运维性和可用性。接下来的架构的革新偏向是提供后端Cache资源的低成本解决方案，从单机的存储容量和单机的极限性能层面不停优化。由于对于微博的营业场景，冷热数据相对比力显着，同时长尾数据请求的比例也不小，因而若是淘汰了Cache的容量，那么会导致后端资源无法抗住请求，而扩大Cache的容量，又会导致成本的铺张。而全内存的解决方案相比而言成底细对比力高，以是热数据存放到内存，基于LRU的计谋把冷数据交流到固体硬盘(SSD)，这是一种可能选择的偏向。
“沈阳软件公司”的新闻页面文章、图片、音频、视频等稿件均为自媒体人、第三方机构发布或转载。如稿件涉及版权等问题，请与
我们联系删除或处理，客服QQ:55506560，稿件内容仅为传递更多信息之目的，不代表本网观点，亦不代表本网站赞同
其观点或证实其内容的真实性。
热门文章
使用“扫一扫”即可将网页分享至朋友圈。
