本文来自。
微博的缓存业务场景
微博几乎所有的接口都是实时组装的。我理解这个实时组装，指的是数据组装。
微博的核心接口的响应时间都是毫秒级的，可用性要达到4个9，99.99%。所以微博大量的使用缓存。
微博最初的缓存架构就是直接利用开源版本的Memcache运行在实体机器上的，称之为裸资源。
在裸资源的初始阶段，微博就对缓存进行分池，分端口存储。把size接近的数据放在一个池子中。业务方通过hash算法，找到对应池子里面对应的节点。同时每个IDC部署都使用独立的缓存资源，为了加速，前端也会用local cache。
如果某个时间点，业务场景中多个缓存节点不可用，大量的请求就会直接请求DB，然后就挂了。
于是使用Main-HA双层架构。
MAIN-HA
什么是MAIN——HA？什么是HA？
HA就是高可用性集群。这个是保证业务连续性的有效结果方案。HA的意思一般是有两个或者两个以上的节点，且分为活动节点和备用节点。通常把正在执行任务的节点称为活动节点，而活动节点的一个备份称为备份节点。当活动节点出现问题时，备份节点检测到，就立即激活称为活动节点来执行任务。从而是业务不中断或者短暂中断。
我理解MAIN-HA就是在HA上又加了一层缓存，先访问MAIN层，MAIN漏了，则打到HA上，主要思想还是保护DB层。
然后做了数据分拆，把核心数据都分拆到了对立的端口。然后出现了调频，也就是数据分层。 更新的是把前端的local cache干掉了。
MAIN－HA还是满足不了突发事件，热数据过多的情况，因为带宽打满了，MC把CPU打满了，然后MC的访问就会变慢。
然后通过排查发现还是热数据的问题，热数据集中访问，导致单个接口不能承载热数据的访问。
L1结构
通过部署3－4组以上小容量的L1缓存，每个L1组等价的存储热数据，来满足业务需求。
L1缓存就是一级缓存，集成在CPU内，在处理数据的过程中，数据暂时保存。
其实就是加一层，现在的缓存结构已经变成 L1 >> MAIN >> HA
这样就做到了低成本，应对高峰、突发流量。
缓存服务化
首先对缓存引入了一个proxy层。引入cluster，内嵌MemcacheCluster访问策略，包括三层的一些更新、读取以及miss后的穿透、回写。
在缓存策略中引入LRU（LEAST RECENTLY USED）最近最少使用。
通过缓存策略(cacheProxy),简化配置，简化开发。业务方只需要知道缓存策略的ip和端口，就可以对后端缓存进行访问。
第一步就是弄了个配置中心。界面化的，可以配置的，多组人员使用。业务方和运维都可以直接用。
第二步，就是有个数据展示中心。
第三步，web化管理，我理解就是第一步的实现。
第四步，监控与报警。
LS4LRU
简单的说就是一个缓存分级策略。缓存因为有过期时间，所以出现了这个LS4LRU的策略。命中的越多，LRU的层级就越高，最高时LRU3，LRU3会持久化，LRU3量太大了，会降级，降到LRU2,重新走缓存命中规则。
总结
1.容灾，就是提到的多层缓存机制。
2.节点异常，有一个界面化的工具，开关部署节点。
3.配置中心异常，快照机制，利用快照来访问缓存策略或者缓存资源。
4.运维就是有个数据展示的地方