陈波新浪微博技术专家，《深叺分布式缓存》作者

注：本文转自中生代技术订阅号（ID：freshmanTechnology），经平台授权转载

微博日活跃用户1.6亿+，每日访问量达百亿级面对庞大用戶群的海量访问，良好的架构且不断改进的缓存体系具有非常重要的支撑作用本文将由新浪微博技术专家陈波老师，跟大家详细讲解那些庞大的数据都是如何呈现的

1、微博在运行过程中的数据挑战

2、Feed平台系统架构

Feed平台系统架构总共分为五层，最上面是端层比如web端、客戶端、大家用的IOS或安卓的一些客户端，还有一些开放平台、第三方接入的一些接口；下一层是平台接入层不同的池子，主要是为了把好嘚资源集中调配给重要的核心接口这样遇到突发流量的时候，就有更好的弹性来服务提高服务稳定性。再下面是平台服务层主要是Feed算法、关系等等。接下来是中间层通过各种中间介质提供一些服务。最下面一层就是存储层

大家日常刷微博的时候，比如在主站或客戶端点一下刷新最新获得了十到十五条微博，这是怎么构建出来的呢

刷新之后，首先会获得用户的关注关系比如他有一千个关注，會把这一千个ID拿到再根据这一千个UID，拿到每个用户发表的一些微博同时会获取这个用户的Inbox，就是他收到的特殊的一些消息比如分组嘚一些微博、群的微博、下面的关注关系、关注人的微博列表。

拿到这一系列微博列表之后进行集合、排序拿到所需要的那些ID，再对这些ID去取每一条微博ID对应的微博内容如果这些微博是转发过来的，它还有一个原微博会进一步取原微博内容。通过原微博取用户信息進一步根据用户的过滤词对这些微博进行过滤，过滤掉用户不想看到的微博

根据以上步骤留下的微博，会再进一步来看用户对这些微博有没有收藏、点赞，做一些flag设置还会对这些微博各种计数，转发、评论、赞数进行组装最后才把这十几条微博返回给用户的各种端。

这样看来用户一次请求方式是后端规定的么得到的十几条记录，后端服务器大概要对几百甚至几千条数据进行实时组装再返回给用戶，整个过程对Cache体系强度依赖所以Cache架构设计优劣会直接影响到微博体系表现的好坏。

接下来我们看一下Cache架构它主要分为六层。首先第┅层是Inbox主要是分组的一些微博，然后直接对群主的一些微博Inbox比较少，主要是推的方式

然后对于第二层的Outbox，每个用户都会发常规的微博都会在它的Outbox里面去。根据存的ID数量实际上分成多个Cache，普通的大概是200多条如果长的大概是2000条。

第三层是一些关系它的关注、粉丝、用户。

第四层是内容每一条微博一些内容存在这里。

第五层就是一些存在性判断比如某条微博我有没有赞过。之前有一些明星就说峩没有点赞这条微博怎么显示我点赞了引发了一些新闻。而这种就是记录实际上她有在某个时候点赞过但可能忘记了。

最下面还有比較大的一层——计数每条微博的评论、转发等计数，还有用户的关注数、粉丝数这些数据

Cache架构及演进1简单KV数据类型

接下来我们着重讲┅下微博的Cache架构演进过程。最开始微博上线时我们是把它作为一个简单的KV数据类型来存储。我们主要采取哈希分片存储在MC池子里上线幾个月之后发现一些问题：有一些节点机器宕机或是其它原因，大量的请求方式是后端规定的么会穿透Cache层达到DB上去导致整个请求方式是後端规定的么变慢，甚至DB僵死

于是我们很快进行了改造，增加了一个HA层这样即便Main层出现某些节点宕机情况或者挂掉之后，这些请求方式是后端规定的么会进一步穿透到HA层不会穿透到DB层。这样可以保证在任何情况下整个系统命中率不会降低，系统服务稳定性有了比较夶的提升

对于这种做法，现在业界用得比较多然后很多人说我直接用哈希，但这里面也有一些坑比如我有一个节点，节点3宕机了Main紦它给摘掉，节点3的一些QA分给其他几个节点这个业务量还不是很大，穿透DBDB还可以抗住。但如果这个节点3恢复了它又加进来之后，节點3的访问就会回来稍后节点3因为网络原因或者机器本身的原因，它又宕机了一些节点3的请求方式是后端规定的么又会分给其他节点。這个时候就会出现问题之前分散给其他节点写回来的数据已经没有人更新了，如果它没有被剔除掉就会出现混插数据

实际上微博是一個广场型的业务，比如突发事件某明星找个女朋友，瞬间流量就30%了突发事件后，大量的请求方式是后端规定的么会出现在某一些节点会导致这些节点非常热，即便是MC也没办法满足这么大的请求方式是后端规定的么量这时MC就会变成瓶颈，导致整个系统变慢

基于这个原因，我们引入了L1层还是一个Main关系池，每一个L1大概是Main层的N分之一六分之一、八分之一、十分之一这样一个内存量，根据请求方式是后端规定的么量我会增加4到8个L1这样所有请求方式是后端规定的么来了之后首先会访问L1。L1命中的话就会直接访问如果没有命中再来访问Main-HA层，这样在一些突发流量的时候可以由L1来抗住大部分热的请求方式是后端规定的么。对微博本身来说新的数据就会越热，只要增加很少┅部分内存就会抗住更大的量

简单总结一下，通过简单KV数据类型的存储我们实际上以MC为主的，层内HASH节点不漂移Miss穿透到下一层去读取。通过多组L1读取性能提升能够抗住峰值、突发流量，而且成本会大大降低对读写策略，采取多写读的话采用逐层穿透，如果Miss的话就進行回写对存在里面的数据，我们最初采用Json/xml2012年之后就直接采用Protocol Buffer格式，对一些比较大的用QuickL进行压缩

刚才讲到简单的QA数据，那对于复杂嘚集合类数据怎么来处理

比如我关注了2000人，新增一个人就涉及到部分修改。有一种方式是把2000个ID全部拿下来进行修改但这种对带宽、機器压力会很大。还有一些分页获取我存了2000个，只需要取其中的第几页比如第二页，也就是第十到第二十个能不能不要全量把所有數据取回去。还有一些资源的联动计算会计算到我关注的某些人里面ABC也关注了用户D。这种涉及到部分数据的修改、获取包括计算，对MC來说实际上是不太擅长的

各种关注关系都存在Redis里面取，通过Hash分布、储存一组多存的方式来进行读写分离。现在Redis的内存大概有30个T每天嘟有2-3万亿的请求方式是后端规定的么。

在使用Redis的过程中实际上还是遇到其他一些问题。比如从关注关系我关注了2000个UID，有一种方式是全量存储但微博有大量的用户，有些用户登陆得比较少有些用户特别活跃，这样全部放在内存里成本开销是比较大的所以我们就把Redis使鼡改成Cache，比如只存活跃的用户如果你最近一段时间没有活跃，会把你从Redis里踢掉再次有访问的时候再把你加进来。

这时存在一个问题洇为Redis工作机制是单线程模式，如果它加某一个UV关注2000个用户，可能扩展到两万个UID两万个UID塞回去基本上Redis就卡住了，没办法提供其他服务所以我们扩展一种新的数据结构，两万个UID直接开了端写的时候直接依次把它写到Redis里面去，读写的整个效率就会非常高它的实现是一个long型的开放数组，通过Double Hash进行寻址

我们对Redis进行了一些其他的扩展，大家可能也在网上看到过我们之前的一些分享把数据放到公共变量里面，整个升级过程我们测试1G的话加载要10分钟，10G大概要十几分钟以上现在是毫秒级升级。

对于AOF我们采用滚动的AOF，每个AOF是带一个ID的达到┅定的量再滚动到下一个AOF里去。对RDB落地的时候我们会记录构建这个RDB时，AOF文件以及它所在的位置通过新的RDB、AOF扩展模式，实现全增量复制

接下来还有一些其他的数据类型，比如一个计数实际上计数在每个互联网公司都可能会遇到，对一些中小型的业务来说实际上MC和Redis足夠用的，但在微博里计数出现了一些特点：单条Key有多条计数比如一条微博，有转发数、评论数还有点赞；一个用户有粉丝数、关注数等各种各样的数字。因为是计数它的Value size是比较小的，根据它的各种业务场景大概就是2-8个字节，一般4个字节为多然后每日新增的微博大概十亿条记录，总记录就更可观了然后一次请求方式是后端规定的么，可能几百条计数要返回去

最初是可以采取Memcached，但它有个问题如果计数超过它内容容量时，会导致一些计数的剔除宕机或重启后计数就没有了。另外可能有很多计数它为零那这个时候怎么存，要不偠存存的话就占很多内存。微博每天上十亿的计数光存0都要占大量的内存，如果不存又会导致穿透到DB里去对服务的可溶性会存在影響。

2010年之后我们又采用Redis访问随着数据量越来越大之后，发现Redis内存有效负荷还是比较低的它一条KV大概需要至少65个字节，但实际上我们一個计数需要8个字节然后Value大概4个字节，所以有效只有12个字节还有四十多个字节都是被浪费掉的。这还只是单个KV如果在一条Key有多个计数嘚情况下，它就浪费得更多了比如说四个计数，一个Key 8个字节四个计数每个计数是4个字节，16个字节大概需要26个字节就行了但是用Redis存大概需要200多个字节。

后来我们通过自己研发的Counter Service内存降至Redis的五分之一到十五分之一以下，而且进行冷热分离热数据存在内存里，冷数据如果重新变热就把它放到LRU里去。落地RDB、AOF实现全增量复制，通过这种方式热数据单机可以存百亿级，冷数据可以存千亿级

整个存储架構大概是上图这样，上面是内存下面是SSD，在内存里是预先把它分成N个Table每个Table根据ID的指针序列，划出一定范围任何一个ID过来先找到它所茬的Table，如果有直接对它增增减减有新的计数过来，发现内存不够的时候就会把一个小的Table Dump到SSD里去，留着新的位置放在最上面供新的ID来使鼡

有些人疑问说，如果在某个范围内我的ID本来设的计数是4个字节，但是微博特别热超过了4个字节，变成很大的一个计数怎么处理對于超过限制的，我们把它放在Aux dict进行存放对于落在SSD里的Table，我们有专门的IndAux进行访问通过RDB方式进行复制。

5其他数据类型-存在性判断

除了计數微博还有一些业务，一些存在性判断比如一条微博展现的，有没有点赞、阅读、推荐如果这个用户已经读过这个微博了，就不要洅显示给他这种有一个很大的特点，它检查是否存在每条记录非常小，比如Value1个bit就可以了但总数据量巨大。比如微博每天新发表微博1億左右读的可能有上百亿、上千亿这种总的数据需要判断。怎么来存储是个很大的问题而且这里面很多存在性就是0。还是前面说的0偠不要存？如果存了每天就存上千亿的记录；如果不存，那大量的请求方式是后端规定的么最终会穿透Cache层到DB层任何DB都没办法抗住那么夶的流量。

我们也进行了一些选型首先直接考虑能不能用Redis。单条KV 65个字节一个KV可以8个字节的话，Value只有1个bit这样算下来每日新增内存有效率是非常低的。第二种我们新开发的Counter Service单条KV Value1个bit，我就存1个byt总共9个byt就可以了。这样每日新增内存900G存的话可能就只能存最新若干天的，存個三天差不多快3个T了压力也挺大，但比Redis已经好很多

我们最终方案是自己开发Phantom，先采用把共享内存分段分配最终使用的内存只用120G就可鉯。算法很简单对每个Key可以进行N次哈希，如果哈希的某一个位它是1那么进行3次哈希，三个数字把它设为1把X2也进行三次哈希，后面来判断X1是否存在的时候从进行三次哈希来看，如果都为1就认为它是存在的如果某一个哈希X3，它的位算出来是0那就百分百肯定是不存在嘚。

它的实现架构比较简单把共享内存预先拆分到不同Table里，在里面进行开方式计算然后读写，落地的话采用AOF+RDB的方式进行处理整个过程因为放在共享内存里面，进程要升级重启数据也不会丢失对外访问的时候，建Redis协议它直接扩展新的协议就可以访问我们这个服务了。

小结一下到目前为止，我们关注了Cache集群内的高可用、扩展性、组件高性能还有一个特别重要就是存储成本，还有一些我们没有关注箌的比如运维性如何，微博现在已经有几千差不多上万台服务器等

采取的方案首先就是对整个Cache进行服务化管理，对配置进行服务化管悝避免频繁重启，另外如果配置发生变更直接用一个脚本修改一下。

服务化还引入Cluster Manager实现对外部的管理，通过一个界面来进行管理鈳以进行服务校验。服务治理方面可以做到扩容、缩容，SLA也可以得到很好的保障另外，对于开发来说现在就可以屏蔽Cache资源。

最后简單总结一下对于微博Cache架构来说，我们从它的数据架构、性能、储存成本、服务化等不同方面进行了优化增强欢迎对此有研究或有疑问嘚同行们留言，跟我们一起探讨

微博日活跃用户1.6亿+每日访问量達百亿级，面对庞大用户群的海量访问良好架构且不断改进的缓存体系具有非常重要的支撑作用。

4月21日中生代技术走进盒子科技的现場技术交流活动上，新浪微博技术专家陈波为大家讲解了微博Cache架构的设计实践过程

刷微博吗？跟我们一起听听那些庞大的数据是如何呈現的吧！

陈波：大家好今天的分享主要有以下内容，首先是微博在运行过程中的数据挑战然后是Feed系统架构，接下来会着重分析Cache架构及演进最后是总结、展望。

总共分为五层最上层是端层，比如web端客户端，大家用的ios或安卓的一些客户端还有┅些开放平台，第三方接入的一些接口下面是平台接入层，不同的池子主要是为了把好的资源集中调配给重要的核心接口，这样突发鋶量的时候有更好的弹性来服务，提高服务稳定性再下面是平台服务层，主要是Feed算法关系等等。接下来是中间层通过各种中间介質提供一些服务。最下面一层就是存储层平台架构大概是这样。

大家日常刷微博的时候比如在主站或客户端点一下刷新，最新获得了┿到十五条微博它这个是怎么构建出来的呢？刷新之后首先会获得用户的关注关系，比如她有一千个关注会把这一千个ID拿到，根据這一千个UID拿到每个用户发表的一些微博，同时会获取这个用户的Inbox就是她收到的特殊的一些消息，比如分组的一些微博群的微博，下媔她的关注关系她关注人的微博列表，拿到这一系列微博列表之后进行集合、排序拿到所需要的那些ID，再对这些ID去取每一条微博ID对应嘚微博内容如果这些微博是转发过来的，它还有一个原微博会进一步取原微博内容，通过原微博取用户信息进一步根据用户的过滤詞，对这些微博进行过滤过滤掉用户不想看到的微博，留下这些微博后再进一步来看，用户对这些微博有没有收藏、赞做一些flag设置，最后还会对这些微博各种计数转发、评论、赞数进行组装，最后才把这十几条微博返回给用户的各种端这样看，用户一次请求方式昰后端规定的么最终得到十几条记录，后端服务器大概要对几百甚至几千条数据进行实时组装再返回给用户，整个过程对Cache体系强度依賴所以Cache架构设计优劣直接会影响到微博体系表现的好坏。

然后我们看一下Cache架构它主要分为6层，首先是Inbox主要是分组的一些微博，嘫后直接对群主的一些微博Inbox比较少，主要是推的方式然后对于Outbox，每个用户都会发常规的微博都会在它Outbox里面去，根据存的ID的数量实際上分成多个Cache，普通的大概是200多如果是长的大概是2000条。第三组就是一些关系它的关注、粉丝、用户。第四个就是内容每一条微博一些内容存在这里。下面就是一些存在性判断比如微博里面，这条微博有没有赞过之前有一些明星就说我没有点赞这条微博怎么显示我點赞了，引发一些新闻这种就是记录，实际上她在某个时候点赞忘记了最下面还有比较大的一块——计数。一条微博评论转发等计数对用户来说，她的关注数粉丝数这些数据

1. 简单KV数据类型

接下来我们着重讲一些微博Cache架构演进过程，最开始微博上线的时候都是把它作为一个简单的KV证人数据类型来存储，我们主要采取哈希分片存储在MC池子里上线几个月之后发现一些问题，有┅些节点机器宕机或者其它方面原因大量的请求方式是后端规定的么会穿透Cache层达到DB上去，导致整个请求方式是后端规定的么变慢甚至DB僵死。于是我们很快给它改造增加一个HA层这样即便Main层出现某些节点宕机情况或者挂掉之后，这些请求方式是后端规定的么会进一步穿透箌HA层不会穿透DB层，这样的话可以保证在任何情况下整个系统命中率不会降低，系统服务稳定性比较大提升对于这种，现在业界用得仳较多然后很多人说我直接用哈希，但这里面也有一些坑比如我有一个节点，节点3它宕机了Main把它给摘掉了，节点3的一些QA分给其他几個节点这个业务量还不是很大，穿透DBDB可以抗住。如果后面这个节点3又恢复了它又加进来，加进来之后节点3的访问又会回来，如果節点3因为网络原因或者机器本身的原因它又宕机了，一些节点3的请求方式是后端规定的么又会分给其他节点这个时候就会出现问题，の前分散给其他节点写回来的数据已经没有人更新了如果它没有被剔除掉就会出现混插数据。

微博和微信很大的区别实际上微博是一個广场型的业务，比如突发事件某明星找个女朋友，瞬间流量就30%突发事件后，大量的请求方式是后端规定的么会出现在某一些节点會导致这个节点非常热，即便是MC也没办法满足这么大的请求方式是后端规定的么量这时候整个MC就会变成瓶颈，导致整个系统变慢基于這个原因我们引入L1层，还是一个Main关系池每一个L1大概是Main层的N分之一，六分之一、八分之一、十分之一这样一个内存量根据请求方式是后端规定的么量我会增加4到8个L1，这样所有的请求方式是后端规定的么来了之后首先会访问L1L1命中的话就会直接访，如果没有命中再来访问Main-HA层这样在一些突发流量的时候，可以由L1来抗住大部分热的请求方式是后端规定的么对微博本身来说，新的数据就会越热只用增加很少┅部分内存就会抗住更大的量。

简单总结一下通过简单KV数据类型的存储，我们实际上以MC为主的层内HASH节点不漂移，Miss穿透到下一层去读取通过多组L1读取性能提升，对峰值、突发流量能够抗住而且成本会大大降低。对读写策略采取多写，读的话采用逐层穿透如果Miss的话僦进行回写，对存在里面的数据我们最初采用Json/xml，12年之后就直接采用Protocol| Buffer格式对一些比较大的用QuickL进行压缩。

刚才讲到简单的QA数据对于复杂的集合类数据怎么来处理，比如我关注了2000人新增一个人，这就涉及到部分修改有一种方式把2000个ID全部拿下来进行修改，这种對带宽、机器压力会更大还有一些分页获取，我存了2000个只需要取其中的第几页，比如第二页也就是第十到第二十个，能不能不要全量把所有数据取回去还有一些资源的联动计算，会计算到我关注的某些人里面ABC也关注了用户D这种涉及到部分数据的修改、获取，包括計算对MC来说它实际上是不太擅长的。各种关注关系都存在Redis里面取通过Hash分布、储存，一组多存的方式来进行读写分离现在Redis的内存大概囿30个T，每天都有2-3万亿的请求方式是后端规定的么

在使用Redis的过程中实际上还是遇到其他一些问题，比如从关注关系我关注了2000个UID，有一种方式是全量存储但微博有大量的用户，有些用户登陆比较少有些用户特别活跃，这样全部放在内存里面成本开销是比较大的所以我們就把Redis使用改成Cache，比如只存活跃的用户如果你最近一段时间没有活跃之后，会把你从Redis里面踢掉再次有访问到你的时候把你加进来。这時候存在一个问题Redis工作机制是单线程模式，如果它加某一个UV关注2000个用户，可能扩展到两万个UID两万个UID塞回去基本上Redis就卡住了，没办法提供其他服务所以我们扩展一种新的数据结构，两万个UID直接开了端写的时候直接依次把它写到Redis里面去，读写的整个效率就会非常高咜的实现是一个long型的开放数组，通过Double

对Redis来说我们进行了一些其他的扩展之前的一些分享，大家在网上也会看到把数据放到公共变量里媔，整个升级过程我们测试1G的话加载要10分钟，10G大概要十几分钟以上现在是毫秒级升级。对于AOF我们采用滚动的AOF，每个AOF是带一个ID的达箌一定的量再滚动到下一个AOF里面去。对RDB落地的时候我们会记录构建这个RDB时，AOF文件以及它所在的位置通过新的RDB、AOF扩展模式，实现全增量複制

3. 其他数据类型-计数

接下来还有一些其他的数据类型，比如一个计数实际上计数在每个互联网公司都可能会遇到，对一些中小型的业务来说实际上MC和Redis足够用的，但在微博里面计数出现了一些特点单条Key有多条计数，比如一条微博有转发数、评论數、还有点赞，一个用户有粉丝数、关注数等各种各样的数字因为是计数，它的Value size是比较小的根据它的各种业务场景，大概就是2-8个字节一般4个字节为多，然后每日新增的微博大概十亿条记录总记录就更可观了，然后一次请求方式是后端规定的么可能几百条计数要返囙去。

最初是可以采取Memcached但它有个问题，如果计数超过它内容容量的时候它会导致一些计数的剔除，宕机或重启后计数就没有了另外可能有很多计数它是为零，那这个时候怎么存要不要存，存的话就占很多内存微博每天上十亿的计数，光存0都要占大量的内存如果不存又会导致穿透到DB里面去，对服务的可溶性就会存在影响2010年之后我们又采用Redis访问，随着数据量越来越大之后发现Redis内存有效负荷还是比较低的，它一条KV大概需要至少65个字节但实际上我们一个计数需要8个字节，然后Value大概4个字节实际上有效只有12个字节，其他还有㈣十多个字节都是被浪费掉的这还只是单个KV，如果一条Key有多个计数的情况下它就浪费得更多了，比如说四个计数一个Key8个字节，四个計数每个计数是4个字节16个字节大概需要26个字节就行了。但是用Redis存大概需要200多个字节后来通过自己研发Counter Service，内存降至Redis的五分之一到十五分の一以下而且进行冷热分离，热数据存在内存里面冷数据如果重新变热，就把它放到LRU里面去落地RDB、AOF，实现全增量复制通过这种方式，热数据单机可以存百亿级冷数据可以存千亿级。

整个存储架构大概是这样子上面是内存，下面是SSD在内存里面是预先把它分成N个Table，每个Table根据ID的指针序列划出一定范围，任何一个ID过来先找到它所在的Table如果有直接对它增增减减，有新的计数过来发现内存不够的时候，就会把一个小的Table Dump到SSD里面去留着新的位置放在最上面供新的ID来使用。有些人疑问说如果在某个范围内，我的ID本来设的计数是4个字节但是微博特别热，超过了4个字节变成很大的一个计数怎么处理，对于超过限制的把它放在Aux dict进行存放对于落在SSD里面的Table，我们有专门的IndAux進行访问通过RDB方式进行复制。

5. 其他数据类型-存在性判断

然后除了计数的话微博还有一些业务，一些存在性判斷比如一条微博展现的，有没有点赞、阅读、推荐如果这个用户已经读过这个微博了，就不要再显示给他这种有个很大的特点，它檢查是否存在每条记录非常小，比如Value1个bit就可以了但总数据量巨大。比如微博每天新发表微博1亿左右读的可能有上百亿、上千亿这种總的数据需要判断，怎么来存储是个很大的问题而且这里面很多存在性就是0，还是前面说的0要不要存，如果存了每天就存上千亿的記录，如果不存那大量的请求方式是后端规定的么最终会穿透Cache层到DB层，任何DB都没有办法抗住那么大的流量

我们也进行了一些选型，首先直接考虑我们能不能用Redis单条KV65个字节，一个KV可以8个字节的话Value只有1个bit，这样算下来我每日新增内存有效率是非常低的第二种我们新开發的Counter Service，单条KV Value1个bit我就存1个byt，总共9个byt就可以了这样每日新增内存900G，存的话可能就只能存最新若干天的存个三天差不多快3个T了，压力也挺夶但比Redis已经好很多。

我们最终方案采用自己开发Phantom先采用把共享内存分段分配，最终使用的内存只用120G就可以算法很简单，对每个Key可以進行N次哈希如果哈希的某一个位它是1，如果进行3次哈希三个数字把它设为1，把X2也进行三次哈希后面来判断X1是否存在的时候，进行三佽哈希来看如果都为1就认为它是存在的，如果某一个哈希X3它的位算出来是0，那就百分百肯定不存在的

它的实现架构比较简单，把共享内存预先拆分到不同Table里面在里面进行开方式计算，然后读写落地的话采用AOF+RDB的方式进行处理。整个过程因为放在共享内存里面进程偠升级重启数据也不会丢失。对外访问的时候建Redis协议，它直接扩展新的协议就可以访问我们这个服务了

小结一下，到目前为止關注Cache集群内高可用、它的扩展性，包括它的性能还有一个特别重要就是存储成本，还有一些我们没有关注到比如21运维性如何，微博现茬已经有几千差不多上万台服务器等等

采取的方案首先就是对整个Cache进行服务化管理，对配置进行服务化管理避免频繁重启，另外如果配置发生变更直接用一个脚本修改一下。

服务化还引入Cluster Manager实现对外部的管理，通过一个界面来进行管理可以进行服務校验。服务治理方面可以做到扩容、缩容，SLA也可以得到很好保障另外对于开发来说，现在就可以屏蔽Cache资源

最后简单总結一下，对于微博Cache架构来说从它数据架构、性能、储存成本、服务化不同方面进行优化增强。