本文来自简书。
微博的缓存业务场景
微博几乎所有的接口都是实时组装的。我理解这个实时组装,指的是数据组装。
微博的核心接口的响应时间都是毫秒级的,可用性要达到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.运维就是有个数据展示的地方