缓存#

缓存就是数据交换的缓冲区（称作Cache [ kae]] )，是存贮数据的临时地方，一般读写性能较高。

• 优点
  • 降低后端的负载
  • 提高读写效率，降低响应的时间
• 成本
  • 数据一致性成本
  • 代码维护成本
  • 运维成本

应用先查询 Redis，命中时直接返回，未命中时查询数据库并回填带有效期的缓存。修改数据时先提交数据库更新，再让对应缓存失效，后续读取重新加载。缓存减少重复查询，但数据库与缓存之间的失败窗口仍需处理，不能仅靠设置有效期宣称两者始终一致。

缓存更新策略#

业务场景:
低一致性需求:使用内存淘汰机制。例如店铺类型的查询缓存
高一致性需求:主动更新，并以超时剔除作为兜底方案。例如店铺详情查询的缓存

主动更新

• 由缓存的调用者，在更新数据库的同时更新缓存
• 缓存与数据库整合为一个服务，由服务来维护一致性。调用者调用该服务，无需关心缓存一致性问题。
• 调用者只操作缓存，由其它线程异步的将缓存数据持久化到数据库，保证最终一致。

缓存更新策略的最佳实践方案:
1.低一致性需求:使用Redis自带的内存淘汰机制
2.高一致性需求:主动更新，并以超时剔除作为兜底方案

• 读操作︰
  • 缓存命中则直接返回
  • 缓存未命中则查询数据库，并写入缓存，设定超时时间
• 写操作∶
  • 先写数据库，然后再删除缓存
  • 要确保数据库与缓存操作的原子性

先写数据库再删除缓存，是让下一次读取重新加载最新数据，而不是给旧缓存逐字段打补丁。数据库提交与缓存删除属于两个操作，删除失败需要重试或补偿，超时剔除只能限制陈旧数据存续的窗口，不能自动提供跨存储的原子性，也不能消除所有并发回填竞态。

*缓存穿透#

==缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在，这样缓存永远不会生效，这些请求都会打到数据库。==

恶意用户在发送请求后发现为空，而查询每次都要到数据库，长此以往会导致数据库压力过大。

• 缓存空对象
  • 优点:实现简单，维护方便
  • 缺点:
    • 额外的内存消耗
    • 可能造成短期的不一致
• 布隆过滤器（存伪不失真）存在不一定存在，不存在一定不存在
  • 优点:内存占用较少，没多余key
  • 缺点:
    • 实现复杂
    • 存在误判的可能

数据库查空后，可以短期缓存明确的空值标记，使后续同类请求直接返回不存在；需要区分空标记和真正没有缓存。布隆过滤器能够排除确定不存在的查询，但“可能存在”仍须继续查询，不能当作数据存在的证明。两种方式都需要考虑新增数据和失效维护。

缓存穿透产生的原因是什么?

• 用户请求的数据在缓存中和数据库中都不存在，不断发起这样的请求给数据库带来巨大压力

缓存穿透的解决方案有哪些?

• 缓存null值
• 布隆过滤
• 增强id的复杂度，避免被猜测id规律
• 做好数据的基础格式校验
• 加强用户权限校验
• 做好热点参数的限流

*缓存雪崩#

缓存雪崩是指在同一时段大量的缓存kev同时失效或者Redis服务宕机，导致大量请求到达数据库，带来巨大压力。

解决方案:

• 给不同的Key的TTL添加随机值
• 利用Redis集群提高服务的可用性
• 给缓存业务添加降级限流策略
• 给业务添加多级缓存

*缓存击穿#

缓存击穿问题也叫热点Key问题，就是一个被高并发访问并且缓存重建业务较复杂的key突然失效了，无数的请求访问会在瞬间给数据库带来巨大的冲击。

击穿的对象是原本存在、访问集中的热点键，缓存失效后大量请求同时回源；穿透则是缓存和数据库都没有对应数据，雪崩涉及大量键失效或整个缓存服务不可用。先定位触发范围，再决定使用空值缓存、互斥重建、错开有效期或业务降级，避免把不同故障当作同一问题处理。

==常见的解决方案有两种:==

• 互斥锁
• 逻辑过期

互斥方案让获锁请求再次检查缓存，再按需回源重建，其他请求等待或重试；逻辑过期方案保留旧值，发现过期时先返回旧数据，仅让获锁任务后台更新。后者以暂时陈旧换取读取不等待，但缓存真实缺失时没有旧值可用，仍需冷启动或回源策略。