Redis 缓存一致性问题
场景
抢券，下单，库存扣减，使用redis库存扣减，然后在更新数据库，结果就导致redis库存扣减成功了，数据库更新失败或者redis下面的代码执行异常导致事务回滚，但是redis却没有回滚，就会导致，数据库库存数量没扣减，但是redis库存扣减了。
分析
需要从两个方面分析 要想保证缓存和数据库「实时」一致性 就需要解决两个问题 1 异常情况， 2 并发情况
更新方案
- 先更新缓存，后更新数据库
- 先更新数据库，后更新缓存
异常情况下都会导致 缓存脏数据
并发情况下 也会出问题 如下例子
- 线程 A 更新数据库（X = 1）
- 线程 B 更新数据库（X = 2）
- 线程 B 更新缓存（X = 2）
- 线程 A 更新缓存（X = 1）
最终 X 的值在缓存中是 1，在数据库中是 2，发生不一致
并发问题 通常解决方案
「分布式锁」两个线程要修改「同一条」数据，每个线程在改之前，先去申请分布式锁，拿到锁的线程才允许更新数据库和缓存，拿不到锁的线程，返回失败，等待下次重试。
删除方案
- 先删除缓存，后更新数据库
- 先更新数据库，后删除缓存
先删除缓存，后更新数据库，第二步操作失败，数据库没有更新成功，那下次读缓存发现不存在，则从数据库中读取，并重建缓存，此时数据库和缓存依旧保持一致。
但如果是先更新数据库，后删除缓存，第二步操作失败，数据库是最新值，缓存中是旧值，发生不一致。所以，这个方案依旧存在问题。
并发情况下 问题
- 线程 A 要更新 X = 2（原值 X = 1）
- 线程 A 先删除缓存
- 线程 B 读缓存，发现不存在，从数据库中读取到旧值（X = 1）
- 线程 A 将新值写入数据库（X = 2）
- 线程 B 将旧值写入缓存（X = 1）
最终 X 的值在缓存中是 1（旧值），在数据库中是 2（新值），发生不一致。
依旧是 2 个线程并发「读写」数据：
- 缓存中 X 不存在（数据库 X = 1）
2.线程 A 读取数据库，得到旧值（X = 1） - 线程 B 更新数据库（X = 2)
- 线程 B 删除缓存
- 线程 A 将旧值写入缓存（X = 1）
最终 X 的值在缓存中是 1（旧值），在数据库中是 2（新值），也发生不一致。
这种情况「理论」来说是可能发生的，但是 概率「很低」因为它必须满足 3 个条件：
- 缓存刚好已失效
- 读请求 + 写请求并发
- 更新数据库 + 删除缓存的时间（步骤 3-4），要比读数据库 + 写缓存时间短（步骤 2 和 5）
如何保证两步都执行成功？
保证第二步成功执行，就是解决问题的关键。
答案是：异步重试。
把重试请求写到「消息队列」中，然后由专门的消费者来重试，直到成功
或者另外一个方案就是 订阅数据库变更日志，再操作缓存。 例如阿里的 canal
至此，我们可以得出结论，想要保证数据库和缓存一致性，推荐采用「先更新数据库，再删除缓存」方案，并配合「消息队列」或「订阅变更日志」的方式来做。
主从库延迟和延迟双删问题
- 线程 A 更新主库 X = 2（原值 X = 1）
- 线程 A 删除缓存
- 线程 B 查询缓存，没有命中，查询「从库」得到旧值（从库 X = 1）
- 从库「同步」完成（主从库 X = 2）
- 线程 B 将「旧值」写入缓存（X = 1）
最终 X 的值在缓存中是 1（旧值），在主从库中是 2（新值），也发生不一致。
在线程 A 删除缓存、更新完数据库之后，先「休眠一会」，再「删除」一次缓存。（可以 线程 A 可以生成一条「延时消息」，写到消息队列中，消费者延时「删除」缓存。）
可以做到强一致吗？
要想做到强一致，最常见的方案是 2PC、3PC、Paxos、Raft 这类一致性协议，但它们的性能往往比较差，而且这些方案也比较复杂，还要考虑各种容错问题。
这时我们换个角度思考一下，我们引入缓存的目的是什么
没错，性能。
一旦我们决定使用缓存，那必然要面临一致性问题。性能和一致性就像天平的两端，无法做到都满足要求
虽然我们可以通过加「分布锁」的方式来实现，但我们也要付出相应的代价，甚至很可能会超过引入缓存带来的性能提升。
所以，既然决定使用缓存，就必须容忍「一致性」问题，我们只能尽可能地去降低问题出现的概率。
参考 ：
How to solve the database and cache consistency problem
