缓存和 DB 的数据一致性问题

缓存和DB的数据不一致主要有两种情况：

1. 并发的场景下，导致读取旧的 DB 数据，更新到缓存中。
2. 缓存和 DB 的操作，不在一个事务中，可能只有一个操作成功，而另一个操作失败，导致不一致。

常用的优化方案，主要是解决两个问题：

1. 将缓存可能存在的并行写，实现串行写。
2. 实现数据的最终一致性。

下面是我们比较常用到的集中优化手段：

1、先淘汰缓存，再写数据库，注意要引入分布式锁，从而实现串行写的目的。

• 在写请求时，先淘汰缓存之前，获取该分布式锁。
• 在读请求时，发现缓存不存在时，先获取分布式锁。

2、先写数据库，再更新缓存

这时候需要保证 DB 和缓存的操作在“同一个事务”中，从而实现最终一致性。

下面有两种实现方式：

① 基于定时任务来实现

• 首先，写入数据库。
• 然后，在写入数据库所在的事务中，插入一条记录到任务表。该记录会存储需要更新的缓存 key和 value。
• 最后，定时任务每秒扫描任务表，更新到缓存中，之后删除该记录。

② 基于消息队列来实现

• 先写入数据库。
• 然后，在发送带有缓存key和value 的事务消息。比如阿里的 RocketMQ 就支持消息事务。
• 最后，消费者消费该消息，更新到缓存中。

3、基于数据库的 binlog 日志

• 数据直接写入数据库。
• 数据库更新binlog日志（注意：数据库要开启binlog为row模式，因为canal读取binlog日志格式要求如此）。
• 利用阿里的Canal中间件读取binlog日志。
• Canal借助于限流组件按频率将数据发到MQ中。
• 将MQ的数据更新到Redis缓存中。

       虽然这种方式实现了缓存与DB的一致性，但是需要引入多余的第三方组件来实现，实际项目还是要根据具体的需求来确定是否使用该方案。在之前的做过的一个项目中，我们就是使用了mysql, canal, kafka, Elasticsearch, 实现了Elasticsearch与mysql之间的数据一致性。

参考：https://www.w3cschool.cn/architectroad/architectroad-consistency-of-cache-with-database.html

          https://www.w3cschool.cn/architectroad/architectroad-consistency-of-cache-with-master-and-slave-database.html

          https://www.w3cschool.cn/architectroad/architectroad-master-and-slave-database-architecture-optimization.html