持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第17天，点击查看活动详情
先操作缓存还是操作数据库
若先修改缓存再更新数据库，在高并发的情况下，会造成数据大量的迭代增加服务器的压力，同时，部分数据并不大量调用，造成资源的浪费。 所以，合理的方案是先更新数据库再更新缓存
主动更新策略
1. read/write through 缓存代理
采用分布式缓存组件，应用程序只和缓存交互，不再和数据库交互，而是由缓存和数据库交互，相当于更新数据库的操作由缓存自己代理了。 写策略的步骤： 当有数据更新的时候，先查询要写入的数据在缓存中是否已经存在：
- 如果缓存中数据已经存在，则更新缓存中的数据，并且由缓存组件同步更新到数据库中，最后告知应用程序更新完成。
- 如果缓存中数据不存在，直接更新数据库，然后返回； 读策略的步骤： 先查询缓存中数据是否存在，如果存在则直接返回，如果不存在，则由缓存组件负责从数据库查询数据，并将结果写入到缓存组件，最后缓存组件将数据返回。
2. Write Back（写回）策略
Write Back（写回）策略在更新数据的时候，只更新缓存，同时将缓存数据设置为脏的，然后立马返回，不更新数据库。而我们的缓存会异步地批量更新数据库。 特别适合写多的场景 问题显而易见 数据不是强一致性，可能会丢失数据
3. Cache Aside（旁路缓存）策略
写策略的步骤：
- 先更新数据库中的数据，再删除缓存中的数据。 读策略的步骤：
- 如果读取的数据命中了缓存，则直接返回数据；
- 如果读取的数据没有命中缓存，则从数据库中读取数据，然后将数据写入到缓存，并且返回给用户。 因此适合读多写少的情况
操作缓存和数据库时有三个问题需要考虑：
删除缓存还是更新缓存？
- 更新缓存：每次更新数据库都更新缓存，无效写操作较多
- 删除缓存：更新数据库时让缓存失效，查询时再更新缓存
如何保证缓存与数据库的操作的同时成功或失败？
- 单体系统，将缓存与数据库操作放在一个事务
- 分布式系统，利用TCC等分布式事务方案
先删除缓存的缺点
正常情况下
出现错误的情况
正常情况下
出现错误的情况
可以看到，先操作数据库再删除缓存出现数据不一致的可能性还存在
需要满足以下条件：
- 两个线程并发执行
- 线程1执行时恰好缓存失效
- 线程1查完数据库进行写缓存的微秒时刻线程2更新数据库，删缓存 在这微小时刻进行数据库的写入（耗时长）可能性不大，所以选择先操作数据库，再删除缓存。
总结
缓存更新策略的最佳实践方案：
- 低一致性需求：使用Redis自带的内存淘汰机制
- 高一致性需求：主动更新，并以超时剔除作为兜底方案
读操作：
- 缓存命中则直接返回
- 缓存未命中则查询数据库，并写入缓存，设定超时时间
写操作：
- 先写数据库，然后再删除缓存
- 要确保数据库与缓存操作的原子性 即给缓存添加超时剔除和主动更新的策略，可以解决大部分的数据一致性问题
其他问题
1. 缓存穿透
客户端请求的数据在缓存中和数据库中都不存在，这样缓存永远不会生效，这些请求都会打到数据库。 给服务器带来很大的压力
解决方案
1.1 缓存空对象 优点：实现简单，维护方便 缺点： 额外的内存消耗，可能造成短期的不一致
1.2 布隆过滤 优点：内存占用较少，没有多余key 缺点：实现复杂，存在误判可能
2.缓存雪崩
缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机，导致大量请求到达数据库，带来巨大压力。 解决方案
- 给不同的Key的TTL添加随机值
- 利用Redis集群提高服务的可用性
- 给缓存业务添加降级限流策略
- 给业务添加多级缓存
3.缓存击穿
缓存击穿问题也叫热点Key问题，就是一个被高并发访问并且缓存重建业务较复杂的key突然失效了，无数的请求访问会在瞬间给数据库带来巨大的冲击。
解决方案
- 互斥锁
- 逻辑过期（增加一个字段，也要用互斥的原理调用一个线程去数据库获取数据）
