导航：
【Java笔记+踩坑汇总】Java基础+进阶+JavaWeb+SSM+SpringBoot+瑞吉外卖+SpringCloud+黑马旅游+谷粒商城+学成在线+MySQL高级篇+设计模式+常见面试题+源码
目录
一、四种基础同步策略
1.1 同步策略
1.2 更新缓存还是删除缓存？
1.2.1 更新缓存的优缺点
1.2.2 删除缓存的优缺点（推荐）
1.3 先操作数据库还是先删除缓存?
1.3.1 先删除缓存再操作数据库的优缺点
1.3.2 先操作数据库再删除缓存的优缺点（推荐）
1.4 最优同步策略：先更新数据库、再删除缓存
二、同步删除+可靠消息方案
三、延时双删：更高一致性方案
四、异步监听+可靠消息删除方案
五、多重保障：最终强一致方案
一、四种基础同步策略
1.1 同步策略
保证缓存和数据库的双写一致性，共有四种同步策略，即先更新缓存再更新数据库、先更新数据库再更新缓存、先删除缓存再更新数据库、先更新数据库再删除缓存。
- 先更新缓存再更新数据库：第二步失败缓存库是脏数据
- 先更新数据库再更新缓存：第二步失败缓存库是旧数据
- 先删除缓存再更新数据库：第二步失败缓存库是空数据
- 先更新数据库、再删除缓存（推荐）：第二步失败缓存库是旧数据
1.2 更新缓存还是删除缓存？
1.2.1 更新缓存的优缺点
更新缓存的优点是每次数据变化时都能及时地更新缓存，这样不容易出现查询未命中的情况，但这种操作的消耗很大，如果数据需要经过复杂的计算再写入缓存的话，频繁的更新缓存会影响到服务器的性能。如果是写入数据比较频繁的场景，可能会导致频繁的更新缓存却没有业务来读取该数据。
1.2.2 删除缓存的优缺点（推荐）
删除缓存的优点是操作简单，无论更新的操作复杂与否，都是直接删除缓存中的数据。这种做法的缺点则是，当删除了缓存之后，下一次容易出现未命中的情况，那么这时就需要再次读取数据库。
那么对比而言，删除缓存无疑是更好的选择。
1.3 先操作数据库还是先删除缓存?
1.3.1 先删除缓存再操作数据库的优缺点
情况1：数据库和缓存内容不一致
线程1删除缓存后还没有来得及更新数据库时，线程2读缓存，由于缓存中的数据已经被线程1清空了所以线程2需要去数据库读数据，然后把读到的结果保存到缓存中。此时线程1更新更新数据库成功。就会出现数据库和缓存内容不一致。
情况2：缓存击穿，数据库卡死
线程1删除缓存后还没有来得及更新数据库时，来了大量的读请求，由于缓存中没有数据，导致缓存击穿直接将大量请求访问到数据库，导致数据库崩溃。
1.3.2 先操作数据库再删除缓存的优缺点（推荐）
脏数据问题：先操作数据库但删除缓存失败的话，导致缓存库里一直存留着旧数据，而我们数据库里存的是新数据。
解决办法：异步重试机制
出现上述问题的时候，我们一般采用重试机制解决，而为了避免重试机制影响主要业务的执行，一般建议重试机制采用异步的方式执行。当我们采用重试机制之后由于存在并发，先删除缓存依然可能存在缓存中存储了旧的数据，而数据库中存储了新的数据，二者数据不一致的情况。
1.4 最优同步策略：先更新数据库、再删除缓存
所以我们得到结论：先更新数据库、再删除缓存是影响更小的方案。如果第二步出现失败的情况，则可以采用重试机制解决问题。
同步删除方案： 先更新数据库、再删除缓存。适用于不强制要求数据一致性的情景
流程：先更新数据库、再删除缓存。
问题：
- 并发时脏数据：在查询数据库到写缓存期间其他线程执行了一次更新删除，导致缓存的数据是旧数据
- 缓存删除失败：删除失败导致缓存库还是旧数据
二、同步删除+可靠消息方案
同步删除+可靠消息删除： 适用于不强制要求数据一致性的情景
流程：先更新数据库、再删除缓存，如果删除失败就发可靠MQ不断重试删除缓存，直到删除成功或重试5次。
问题：MQ多次重试失败，导致长期脏数据。
三、延时双删：更高一致性方案
延时双删方案：比同步删除策略一致性更高的方案。
流程：先删除缓存再更新数据库，大约在数据库从库更新后再删一次。
问题：时间无法控制，不能保证在数据库从库更新后删除缓存。如果在从库更新前删除，用户再在更新前查从库又把脏数据写在缓存里了。
四、异步监听+可靠消息删除方案
异步监听+可靠消息删除：很多大厂正在使用的方案。
流程：
- 更新数据库后不做操作；
- Canal等组件监听binlog发现有更新时就发可靠MQ删除缓存；
- 如果删除缓存失败，就基于手动ack、retry等机制，让消息在有限次数之内不断重试。
优点：
- 异步删除，性能更高；
- 可靠消息重试机制，多次删除保证删除成功。
问题：要求canal等binlog抓取组件高可用，如果canal故障，会导致长期脏数据。
五、多重保障：最终强一致方案
多重保障方案：同步删除+ 异步监听+可靠消息删除，缓存时设置过期时间，查询时强制主库查；适合于强制要求数据一致性的情况
- 同步删除：先更新数据库、再删除缓存；之后本链路禁止再查该数据，防止没来得及删缓存就又查到旧缓存数据。
- Canal监听：Canal等组件监听binlog发现有更新时就发可靠MQ删除缓存；第二重保证删缓存成功；
- 延迟消息校验一致性：Canal等组件监听binlog，发延迟MQ，N秒后校验缓存一致性；
- 缓存过期时间：每次缓存时设置过期时间；第三重保证删缓存成功；
- 强制Redis主库查：以后查缓存时强制从缓存主库查；因为主从同步有延迟，同时不用担心主库压力大，因为分片集群机制。
