1. 更新数据库和缓存
1.1 先更新数据库后更新缓存
有线程 A 和线程 B 两个线程，需要更新「同一条」数据：
- 线程 A 更新数据库（X = 1）
- 线程 B 更新数据库（X = 2）
- 线程 B 更新缓存（X = 2）
- 线程 A 更新缓存（X = 1）
最终 X 的值在缓存中是 1，在数据库中是 2，发生不一致。
1.2 先更新缓存后更新数据库
有线程 A 和线程 B 两个线程，需要更新「同一条」数据：
- 线程 A 更新缓存（X = 1）
- 线程 B 更新缓存（X = 2）
- 线程 B 更新数据库（X = 2）
- 线程 A 更新数据库（X = 1）
最终 X 的值在缓存中是 2，在数据库中是 1，发生不一致。
2. 更新数据库删除缓存
2.1 先更新数据库后删除缓存
如果有 2 个线程并发「读写」数据：
- 缓存中 X 不存在（数据库 X = 1）
- 线程 A 读取数据库，得到旧值（X = 1）
- 线程 B 更新数据库（X = 2)
- 线程 B 删除缓存
- 线程 A 将旧值写入缓存（X = 1）
最终 X 的值在缓存中是 1（旧值），在数据库中是 2（新值），也发生不一致。
2.2 先删除缓存后更新数据库
如果有 2 个线程要并发「读写」数据：
- 线程 A 要更新 X = 2（原值 X = 1）
- 线程 A 先删除缓存
- 线程 B 读缓存，发现不存在，从数据库中读取到旧值（X = 1）
- 线程 A 将新值写入数据库（X = 2）
- 线程 B 将旧值写入缓存（X = 1）
最终 X 的值在缓存中是 1（旧值），在数据库中是 2（新值），发生不一致。
2.2 重试
2.2.1 同步重试
- 同步重试很大概率「还会失败」
- 「重试次数」设置多少才合理？
- 重试会一直「占用」这个线程资源，无法服务其它客户端请求
2.2.2 异步重试
其实就是把重试请求写到「消息队列」中，然后由专门的消费者来重试，直到成功。
或者更直接的做法，为了避免第二步执行失败，我们可以把操作缓存这一步，直接放到消息队列中，由消费者来操作缓存。
如果在执行失败的线程中一直重试，还没等执行成功，此时如果项目「重启」了，那这次重试请求也就「丢失」了，那这条数据就一直不一致了。
所以，这里我们必须把重试或第二步操作放到另一个「服务」中，这个服务用「消息队列」最为合适。这是因为消息队列的特性，正好符合我们的需求：
3. 引入消息中间件删除缓存
- 消息队列保证可靠性：写到队列中的消息，成功消费之前不会丢失（重启项目也不担心）
- 消息队列保证消息成功投递：下游从队列拉取消息，成功消费后才会删除消息，否则还会继续投递消息给消费者（符合我们重试的场景）
4. 订阅数据库变更日志，再操作缓存
业务应用在修改数据时，「只需」修改数据库，无需操作缓存。拿 MySQL 举例，当一条数据发生修改时，MySQL 就会产生一条变更日志（Binlog），我们可以订阅这个日志，拿到具体操作的数据，然后再根据这条数据，去删除对应的缓存。
订阅变更日志，目前也有了比较成熟的开源中间件，主流的有阿里的 canal，使用这种方案的优点在于：
- 无需考虑写消息队列失败情况：只要写 MySQL 成功，Binlog 肯定会有
- 自动投递到下游队列：canal 自动把数据库变更日志「投递」给下游的消息队列
小结： 「先更新数据库，再删除缓存」方案，并配合「消息队列」或「订阅变更日志」的方式来做。
5. 缓存延迟双删策略
问题一，还记得前面讲到的「先删除缓存，再更新数据库」方案，导致不一致的场景么？
- 在线程 A 删除缓存、更新完数据库之后，先「休眠一会」，再「删除」一次缓存。
问题二：是关于「读写分离 + 主从复制延迟」情况下，缓存和数据库一致性的问题。
- 线程 A 可以生成一条「延时消息」，写到消息队列中，消费者延时「删除」缓存。
「延迟删除」缓存，延迟时间到底设置要多久呢？
- 问题1：延迟时间要大于「主从复制」的延迟时间
- 问题2：延迟时间要大于线程 B 读取数据库 + 写入缓存的时间
这个时间在分布式和高并发场景下，其实是很难评估的 。
很多时候，我们都是凭借经验大致估算这个延迟时间，例如延迟 1-5s，只能尽可能地降低不一致的概率。极端情况下，还是有可能发生不一致。
所以实际使用中，采用「先更新数据库，再删除缓存」的方案，同时，要尽可能地保证「主从复制」不要有太大延迟，降低出问题的概率。
6. 缓存与数据库的强一致性
强一致 最常见的方案是 2PC、3PC、Paxos、Raft 这类一致性协议，但它们的性能往往比较差，而且这些方案也比较复杂，还要考虑各种容错问题。
-
既然决定使用缓存，我们就是为了追求性能，而追求强一致性又会损耗性能。所以「一致性」问题不可根治，我们只能尽可能地去降低问题出现的概率。
-
同时我们也要知道，缓存都是有「失效时间」的，就算在这期间存在短期不一致，我们依旧有失效时间来兜底，这样也能达到 「最终一致性」。
小结与拓展
小结：
1、想要提高应用的性能，可以引入「缓存」来解决
2、引入缓存后，需要考虑缓存和数据库一致性问题，可选的方案有：「更新数据库 + 更新缓存」、「更新数据库 + 删除缓存」
3、更新数据库 + 更新缓存方案，在「并发」场景下无法保证缓存和数据一致性，且存在「缓存资源浪费」和「机器性能浪费」的情况发生
4、在更新数据库 + 删除缓存的方案中，「先删除缓存，再更新数据库」在「并发」场景下依旧有数据不一致问题，解决方案是「延迟双删」，但这个延迟时间很难评估，所以推荐用「先更新数据库，再删除缓存」的方案
5、在「先更新数据库，再删除缓存」方案下，为了保证两步都成功执行，需配合「消息队列」或「订阅变更日志」的方案来做，本质是通过「重试」的方式保证数据一致性
6、在「先更新数据库，再删除缓存」方案下，「读写分离 + 主从库延迟」也会导致缓存和数据库不一致，缓解此问题的方案是「延迟双删」，凭借经验发送「延迟消息」到队列中，延迟删除缓存，同时也要控制主从库延迟，尽可能降低不一致发生的概率
一致性问题的解决方案：
1、性能和一致性不能同时满足，为了性能考虑，通常会采用「最终一致性」的方案
2、掌握缓存和数据库一致性问题，核心问题有 3 点：缓存利用率、并发、缓存 + 数据库一起成功问题
3、失败场景下要保证一致性，常见手段就是「重试」，同步重试会影响吞吐量，所以通常会采用异步重试的方案
4、订阅变更日志的思想，本质是把权威数据源（例如 MySQL）当做 leader 副本，让其它异质系统（例如 Redis / Elasticsearch）成为它的 follower 副本，通过同步变更日志的方式，保证 leader 和 follower 之间保持一致
很多一致性问题，都会采用这些方案来解决，希望我的这些心得对你有所启发。
