经典的缓存架构
可以支持百万流量的三级缓存
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的持久化策略来恢复数据
快速缓存预约
缓存穿透
其实很简单，就是你查询的数据，多级缓存中都没有，大量的数据都直接走到了数据库，容易导致数据库崩溃