## 使用场景 > **减低后端负载：对高消耗的SQL结果进行缓存，例如join结果集/分组统计结果** ## 加速请求响应 > **大量写合并为批量写，如计数器先Redis累加再批量写到DB** ## 缓存更新策略 - **LRU(Least Recently Used)，根据数据的历史访问记录来进行淘汰数据，其核心思想是“如果数据最近被访问过，那么将来被访问的几率也更高，则延迟其淘汰时间” - LRU缓存更新** - **LFU(Least Frequently Used)根据数据的历史访问频率来淘汰数据，其核心思想是“如果数据过去被访问多次，那么将来被访问的频率也更高”- LFU缓存更新** - **FIFO ，根据"先进先出" 思想来更新缓存数据** - **超时剔除 - expire** - **主动更新 - 开发控制生命周期** - **扩展：缓存污染 - 缓存污染降低了缓存的使用率，把不常用的数据读取到缓存，同时会把常用的数据移出缓存，这样会直接降低系统的数据命中率** ## 缓存穿透问题 ### 场景【key不存在，高并发查询数据库】 > **缓存穿透是指使用不存在的key进行大量的高并发查询，导致缓存无法命中，每次请求都要都要穿透到后端数据库查询，使得数据库的压力非常大，甚至导致数据库服务压死。**  ### 解决方法 #### 分布式队列及分布式锁 > **接口层实现api限流、防御DDOS、接口频率限制、网关实现黑名单、用户授权、id检查等** #### 缓存空对象： 如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），仍然把这个空结果进行缓存，但它的过期时间会很短，不超过5分钟。通过这个直接设置的默认值存放到缓存，这样第二次到缓存中获取就有值了，而不会继续访问数据库。当修改或者新增改key的数据信息的时候，需要删除或者更新null缓存值** ##### 存在的问题： 1. **需要更多的键，所以通常设置较短过期时间** 2. **缓存层和存储层数据"短期"不一致**  借用图：高可用架构 #### 布隆过滤器： 对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力。例如Redis可以使用bitMap来实现布隆过滤器。  借用图：高可用架构 ## 缓存击穿问题 ### 【单个热点key失效时，高并发查询数据库】 > **一个存在的热点key，在缓存过期的一刻，同时有大量的请求，这些请求都会击穿到数据库，造成瞬时数据库请求量大压力骤增。** ### 解决方法 #### 使用分布式锁 > **保证在分布式情况下，使用分布式锁保证对于每个key同时只允许只有一个线程查询到后端服务，其他没有获取到锁的权限，只需要等待即可；这种高并发压力直接转移到分布式锁上，对分布式锁的压力非常大。获取到锁的请求将数据写入成功到redis中， 通知没有获取锁的请求直接从Redis获取数据即可** #### 使用本地缓存（双级缓存） > **双击缓存机制** #### 热点不过期 > **设置热点数据永不过期或者异步延长过期时间；** #### **到期前的续命 > **(在value设置一个比过期时间t0小的过期时间值t1，当t1过期的时候，延长t1并做更新缓存操作。)** ## 缓存雪崩问题 > **缓存雪崩是指，由于缓存层承载着大量请求，有效的保护了存储层，但是如果缓存层由于某些原因整体不能提供服务（可能是机器宕机或大量的缓存(key)在同一时间失效 - 过期），于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。** ### 场景【多个key同时失效，高并发查询数据库】 > **缓存雪崩指缓存服务器重启（没有持久化）或者大量的缓存集中在某个时间段失效，突然给数据库产生了巨大的压力，甚至击垮数据库的情况。** ### 解决方案 1. **对不用的数据使用随机动态分布的失效时间** 2. **使用集群化分摊部署我们key** 3. **使用二级缓存** 4. **使用分布式锁** 5. **数据预热**：可以通过缓存reload机制，预先去更新缓存，再即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀 6. 依赖隔离组件为后端限流并降级 **在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。**