经典的缓存架构
可以支持百万流量的三级缓存
cache aside pattern
- 读数据的时候,先读缓存,缓存没有的话,就读数据库,放入缓存,返回响应
- 写数据的时候,先删除缓存,再更新数据库
为什么是删除缓存,而不是更新缓存那?
原因很简单,试想这么场景,数据频繁的被修改,那么缓存就也要不断的重新计算,这个计算是非常消耗资源的,而且你更新了这么多次缓存还不一定能用到,就有点得不偿失了,所以就有了先删除缓存,再更新数据的做法,这样就是减少了非常多次的缓存重新计算的工作量,而是用到了数据的时候,再从数据库中加载到缓存中
缓存雪崩
缓存雪崩这种场景,在缓存架构中是非常重要的一个环节,应对缓存雪崩的解决方案,避免缓存雪崩的时候,造成整个系统崩溃,带来巨大的经济损失
- redis集群彻底崩溃
- 缓存服务大龄对redis的请求hang主,占用资源
- 缓存服务大量的骑牛打到源头服务去查mysql,直接打死mysql
- 源头服务因为mysql被打死也崩溃,对原服务的请求也hang主,占用资源
- 缓存服务大量的资源全部耗费访问redis和源服务无果,最后自己被拖死,无法提供服务
- ng无法访问缓存服务,redis和源服务,只能基于本地缓存提供服务,但是缓存过期后,没有数据提供
- 网站崩溃
事前
redis本身的高可用性,主从架构
建议双机房部署,可以是一套redis cluster,不同机器的,也可以是不同的redis cluster,两套redis cluster之间做一个数据同步,redis集群是可以搭建成树状结构的
事中
ehcache本地缓存
主要是为了应对redis中的数据被清除的现象和预防redis彻底崩溃
多台机器上部署的缓存服务实例的内存中,还有要ehcache的缓存
ehcache还能支撑一阵子
对redis访问的资源隔离
目的:为了避免所有资源hang在redis上
对redis cluster访问失败的情况,做下熔断策略
什么时候判断redis死了,就自动给他熔断,部署redis cluster的降级策略
降级机制: fallback
fail silent模式,failback里面直接返回一个空值,比如一个null,最简单了
对源服务访问的限流以及资源隔离
资源隔离:限制访问商品服务的资源,避免商品故障的时候,所有资源都在访问该商品
目的:为了源头服务在mysql死掉的情况下,可以存活一阵
事后
redis做了备份
redis数据做了备份,直接根据redis的持久化策略来恢复数据
快速缓存预约
缓存穿透
其实很简单,就是你查询的数据,多级缓存中都没有,大量的数据都直接走到了数据库,容易导致数据库崩溃