缓存失效，穿透，雪崩

缓存可以狭义的理解为是挡在DB之前的一层数据块，性能比DB高很多倍。服务系统查数据，首先会查缓存，如果缓存数据不存在，就进一步查 DB，最后查到数据后回种到缓存并返回。缓存里的数据存储基本上都是以 key 为索引进行存储和获取的。

缓存失效

原因
写缓存时一般都会带上一个过期时间，让缓存数据在这个固定的过期时间后被淘汰。一般情况下写入时间肯定是不同的，所以过期也是不同的。但是如果缓存数据是通过定时任务等操作来加载的，那么过期时间就会相同，这批数据如果到时间后，一起过期了，那么大量缓存就不存在了，此时就视为缓存失效
解决方案
让过期时间不相同，在设置过期时间时，使用：过期时间=固定时间+随机时间，比如expireTIime=6h+30min ,就是让一批缓存在6小时后，在30分钟内慢慢的过期，以保证不会一次性大量失效。

缓存穿透

原因
当请求需要查找数据的时候，缓存中查找的key不存在，然后去DB中查询数据，结果也不存在，这样就不会有数据塞回缓存中，那么下一次相同的操作又会重复查DB。一两次这样的错误操作DB可以承受，但如果短时间内大量这种情况发生，就会对DB产生很大的压力，影响正常DB操作。比如有某些脚本机器人无限重复查询。
解决方案
方案一：查询这些不存在的数据时，第一次查 DB，虽然没查到结果返回 NULL，仍然记录这个 key 到缓存，只是这个 key 对应的 value 是一个自定义的默认值。另外可以将正常key与异常key分开存放，同时异常key的过期时间设置的短一点，查询时先查正常缓存，再看异常缓存，最后在DB，如果DB为空塞回异常缓存，不为空塞回正常缓存
方案二：当数据量不是很大的时候，可以构建一个缓存过滤器，记录全量数据的key，这样访问数据时，可以直接通过判断这个 key 是否存在，如果不存在直接返回即可，根本无需查缓存和 DB。缓存过滤器可以用BloomFilter

缓存雪崩

原因
缓存不支持 rehash 导致的系统雪崩不可用:
较多缓存节点不可用时，大量 Cache 访问会失败,压力直接进入DB。
缓存支持 rehash 导致的缓存雪崩不可用:
一致性 Hash 分布+rehash 策略在一般情况下可以很好得运行，但在较大的流量洪峰到临之时，如果大流量 key 比较集中，正好在某 1～2 个缓存节点，缓存节点就会崩溃下线，然后 key 请求又被 rehash 到其他缓存节点，导致其他节点也崩溃，就想癌症扩散了一样，最终整个缓存系统崩溃。
解决方案
方案一：增加多个缓存副本，缓存异常或请求 miss 后，再读取其他缓存副本，而且多个缓存副本尽量部署在不同机架，从而确保在任何情况下，缓存系统都会正常对外提供服务。
方案二：通过各种自动故障转移策略，自动关闭异常接口、停止边缘服务、停止部分非核心功能措施，确保在极端场景下，核心功能的正常运行。