在介绍“如何保持mysql和redis中数据的⼀致性”这个问题之前，我们需要先弄清什么是“⼀致性”，以及不同缓存 策略下出现的”不⼀致“问题，才能提出⽅法解决这种”不⼀致“，进⽽达到”数据的⼀致性“。

⾸先，“数据⼀致”⼀般指的是：缓存中有数据，缓存的数据值 = 数据库中的值。

但根据缓存中是有数据为依据，则”⼀致“可以包含两种情况：

• 缓存中有数据，缓存的数据值 = 数据库中的值
• 缓存中本没有数据，数据库中的值 = 最新值（有请求查询数据库时，会将数据写⼊缓存，则变为上⾯的“⼀ 致”状态）

”数据不⼀致“：缓存的数据值 ≠ 数据库中的值；缓存或者数据库中存在旧值，导致其他线程读到旧数据

根据是否接收写请求，可以把缓存分成读写缓存和只读缓存。

只读缓存：只在缓存进⾏数据查找，即使⽤ “更新数据库+删除缓存” 策略；

读写缓存：需要在缓存中对数据进⾏增删改查，即使⽤ “更新数据库+更新缓存”策略。

只读缓存：新增数据时，直接写⼊数据库；更新（修改/删除）数据时，先删除缓存。

后续，访问这些增删改的数据时，会发⽣缓存缺失，进⽽查询数据库，更新缓存。

• 新增数据时 ，写⼊数据库；访问数据时，缓存缺失，查数据库，更新缓存（始终是处于”数据⼀致“的状态， 不会发⽣数据不⼀致性问题)

• 更新（修改/删除）数据时 ，会有个时序问题：更新数据库与删除缓存的顺序（这个过程会发⽣数据不⼀致性问题）

在更新数据的过程中，可能会有如下问题：

• ⽆并发请求下，其中⼀个操作失败的情况
• 并发请求下，其他线程可能会读到旧值

因此，要想达到数据⼀致性，需要保证两点：

• ⽆并发请求下，保证A和B步骤都能成功执⾏
• 并发请求下，在A和B步骤的间隔中，避免或消除其他线程的影响

接下来，我们针对有/⽆并发场景，进⾏分析并使⽤不同的策略。

A. 无并发情况

⽆并发请求下，在更新数据库和删除缓存值的过程中，因为操作被拆分成两步，那么就很有可能存在“步骤1成功， 步骤2失败”的情况发⽣（由于单线程中步骤1和步骤2是串⾏执⾏的，不太可能会发⽣“步骤2成功，步骤1失败”的情况）。

(1) 先删除缓存，再更新数据库

(2) 先更新数据库，再删除缓存

解决策略：

a.消息队列+异步重试

⽆论使⽤哪⼀种执⾏时序，可以在执⾏步骤1时，将步骤2的请求写⼊消息队列，当步骤2失败时，就可以使⽤重试策略，对失败操作进⾏“补偿”。

具体步骤如下：

1. 把要删除缓存值或者是要更新数据库值操作生成消息，暂存到消息队列中（例如使⽤ Kafka 消息队列）；
2. 当删除缓存值或者是更新数据库值操作成功时，把这些消息从消息队列中去除（丢弃），以免重复操作；
3. 当删除缓存值或者是更新数据库值操作失败时，执⾏失败策略，重试服务从消息队列中重新读取（消费）这些消息，然后再次进⾏删除或更新；
4. 删除或者更新失败时，需要再次进⾏重试，重试超过的⼀定次数，向业务层发送报错信息。

b.订阅Binlog变更日志

• 创建更新缓存服务，接收数据变更的MQ消息，然后消费消息，更新/删除Redis中的缓存数据；
• 使⽤ Binlog 实时更新/删除Redis 缓存。利⽤Canal，即将负责更新缓存的服务伪装成⼀个MySQL 的从节点，从 MySQL 接收 Binlog，解析 Binlog 之后，得到实时的数据变更信息，然后根据变更信息去更新/删除 Redis 缓存；
• MQ+Canal策略，将Canal Server接收到的Binlog数据直接投递到MQ进⾏解耦，使⽤MQ异步消费Binlog日志，以此进⾏数据同步；

不管⽤ MQ/Canal或者MQ+Canal的策略来异步更新缓存，对整个更新服务的数据可靠性和实时性要求都⽐较⾼，如果产⽣数据丢失或者更新延时情况，会造成MySQL和Redis 中的数据不⼀致。因此，使⽤这种策略时，需要考虑出现不同步问题时的降级或补偿方案。

B. 高并发情况

使⽤以上策略后，可以保证在单线程/⽆并发场景下的数据⼀致性。但是，在⾼并发场景下，由于数据库层⾯的读写并发，会引发的数据库与缓存数据不⼀致的问题（本质是后发⽣的读请求先返回了）

(1) 先删除缓存，再更新数据库

假设线程 A 删除缓存值后，由于⽹络延迟等原因导致未及更新数据库，⽽此时，线程 B 开始读取数据时会发现缓存缺失，进⽽去查询数据库。⽽当线程 B 从数据库读取完数据、更新了缓存后，线程 A 才开始更新数据库，此时，会导致缓存中的数据是旧值，⽽数据库中的是最新值，产⽣“数据不⼀致”。其本质就是，本应后发⽣的“B线程读请求” 先于“A线程-写请求”执⾏并返回了。

或者

解决策略：

a.设置缓存过期时间 + 延时双删

通过设置缓存过期时间，若发⽣上述淘汰缓存失败的情况，则在缓存过期后，读请求仍然可以从DB中读取最新数据并更新缓存，可减⼩数据不⼀致的影响范围。虽然在⼀定时间范围内数据有差异，但可以保证数据的最终⼀致性。

此外，还可以通过延时双删进⾏保障：在线程 A 更新完数据库值以后，让它先 sleep ⼀⼩段时间，确保线程 B 能 够先从数据库读取数据，再把缺失的数据写⼊缓存，然后，线程 A 再进⾏删除。后续，其它线程读取数据时，发现缓存缺失，会从数据库中读取最新值。

redis.delKey(X)
db.update(X)
Thread.sleep(N)
redis.delKey(X)

sleep时间：在业务程序运行的时候，统计下线程读数据和写缓存的操作时间，以此为基础来进⾏估算

注意：如果难以接受sleep这种写法，可以使⽤延时队列进⾏替代。

先删除缓存值再更新数据库，有可能导致请求因缓存缺失而访问数据库，给数据库带来压力，也就是缓存穿透的问题。针对缓存穿透问题，可以⽤缓存空结果、布隆过滤器进⾏解决。

(2) 先更新数据库，再删除缓存

如果线程 A 更新了数据库中的值，但还没来得及删除缓存值，线程 B 就开始读取数据了，那么此时，线程 B 查询缓存时，发现缓存命中，就会直接从缓存中读取旧值。其本质也是，本应后发⽣的“B线程-读请求”先于“A线程-删 除缓存“ 执行并返回了。

或者，在”先更新数据库，再删除缓存”⽅案下，“读写分离 + 主从库延迟”也会导致不⼀致：

解决方案：

a.延迟消息

凭借经验发送「延迟消息」到队列中，延迟删除缓存，同时也要控制主从库延迟，尽可能降低不⼀致发⽣的概率。

b.订阅binlog，异步删除

通过数据库的binlog来异步淘汰key，利⽤⼯具(canal)将binlog⽇志采集发送到MQ中，然后通过ACK机制确认处理 删除缓存。

c.删除消息写入数据库

通过⽐对数据库中的数据，进⾏删除确认

先更新数据库再删除缓存，有可能导致请求因缓存缺失⽽访问数据库，给数据库带来压⼒，也就是缓存穿透的问 题。针对缓存穿透问题，可以⽤缓存空结果、布隆过滤器进⾏解决。

d.加锁

更新数据时，加写锁；查询数据时，加读锁

保证两步操作的“原⼦性”，使得操作可以串⾏执行。“原⼦性”的本质是什么？不可分割只是外在表现，其本质是多个资源间有⼀致性的要求，操作的中间状态对外不可见。

建议：

优先使用“先更新数据库再删除缓存”的执行时序，原因主要有两个：

1. 先删除缓存值再更新数据库，有可能导致请求因缓存缺失⽽访问数据库，给数据库带来压力； 2. 业务应用中读取数据库和写缓存的时间有时不好估算，进⽽导致延迟双删中的sleep时间不好设置。

读写缓存：增删改在缓存中进⾏，并采取相应的回写策略，同步数据到数据库中

• 同步直写：使⽤事务，保证缓存和数据更新的原⼦性，并进⾏失败重试（如果Redis 本身出现故障，会降低 服务的性能和可⽤性）
• 异步回写：写缓存时不同步写数据库，等到数据从缓存中淘汰时，再写回数据库（没写回数据库前，缓存发生故障，会造成数据丢失） 该策略在秒杀场中有⻅到过，业务层直接对缓存中的秒杀商品库存信息进⾏操作，⼀段时间后再回写数据库。

⼀致性：同步直写 > 异步回写

因此，对于读写缓存，要保持数据强⼀致性的主要思路是：利⽤同步直写

同步直写也存在两个操作的时序问题：更新数据库和更新缓存

A. 无并发情况

B. 高并发情况

有四种场景会造成数据不⼀致：

针对场景1和2的解决⽅案是：保存请求对缓存的读取记录，延时消息⽐较，发现不⼀致后，做业务补偿

针对场景3和4的解决⽅案是：对于写请求，需要配合分布式锁使用。写请求进来时，针对同⼀个资源的修改操作，先加分布式锁，保证同⼀时间只有⼀个线程去更新数据库和缓存；没有拿到锁的线程把操作放⼊到队列中，延时处理。⽤这种⽅式保证多个线程操作同⼀资源的顺序性，以此保证⼀致性。

其中，分布式锁的实现可以使⽤以下策略：

上述策略只能保证数据的最终⼀致性。

要想做到强⼀致，最常见的⽅案是 2PC、3PC、Paxos、Raft 这类⼀致性协议，但它们的性能往往⽐较差，⽽且这 些⽅案也⽐较复杂，还要考虑各种容错问题。

如果业务层要求必须读取数据的强⼀致性，可以采取以下策略：

（1）暂存并发读请求

在更新数据库时，先在 Redis 缓存客户端暂存并发读请求，等数据库更新完、缓存值删除后，再读取数据，从而保证数据⼀致性。

（2）串行化

读写请求入队列，⼯作线程从队列中取任务来依次执⾏

1. 修改服务Service连接池，id取模选取服务连接，能够保证同⼀个数据的读写都落在同⼀个后端服务上
2. 修改数据库DB连接池，id取模选取DB连接，能够保证同⼀个数据的读写在数据库层⾯是串行的

（3）使用Redis分布式读写锁

将淘汰缓存与更新库表放入同⼀把写锁中，与其它读请求互斥，防⽌其间产⽣旧数据。读写互斥、写写互斥、读读共享，可满⾜读多写少的场景数据⼀致，也保证了并发性。并根据逻辑平均运⾏时间、响应超时时间来确定过期时间。

public void write() {
 Lock writeLock = redis.getWriteLock(lockKey);
 writeLock.lock();
 try {
 redis.delete(key);
 db.update(record);
 } finally {
 writeLock.unlock();
 }
}
public void read() {
 if (caching) {
 return;
 }
 // no cache
 Lock readLock = redis.getReadLock(lockKey);
 readLock.lock();
 try {
 record = db.get();
 } finally {
 readLock.unlock();
 }
 redis.set(key, record);
}

针对读写缓存时：同步直写，更新数据库+更新缓存

针对只读缓存时：更新数据库+删除缓存

较为通用的⼀致性策略拟定：

在并发场景下，使⽤ “更新数据库 + 更新缓存” 需要⽤分布式锁保证缓存和数据⼀致性，且可能存在”缓存资源浪费 “和”机器性能浪费“的情况；⼀般推荐使用“更新数据库 + 删除缓存”的⽅案。如果根据需要，热点数据较多，可以使用“更新数据库 + 更新缓存”策略。

在“更新数据库 + 删除缓存”的⽅案中，推荐使⽤推荐⽤ “先更新数据库，再删除缓存” 策略，因为先删除缓存可能 会导致⼤量请求落到数据库，⽽且延迟双删的时间很难评估。

在“先更新数据库，再删除缓存”策略中，可以使⽤“消息队列+重试机制”的⽅案保证缓存的删除。并通过“订阅binlog”进⾏缓存比对，加上⼀层保障。

此外，需要通过初始化缓存预热、多数据源触发、延迟消息⽐对等策略进⾏辅助和补偿。

【多种数据更新触发源：定时任务扫描，业务系统 MQ、binlog 变更 MQ，相互之间作为互补来保证数据不会漏更新】

此外，还需要考虑其他的问题细节，以保证缓存系统的可⽤性、健壮性与⾼效性

(1) k-v大小的合理设置

Redis key大小设计： 由于⽹络的⼀次传输MTU最⼤为1500字节，所以为了保证⾼效的性能，建议单个k-v⼤⼩不超过1KB，⼀次 ⽹络传输就能完成，避免多次⽹络交互；k-v是越⼩性能越好
Redis 热key：（1） 当业务遇到单个读热key，通过增加副本来提⾼读能⼒或是⽤hashtag把key存多份在 多个分⽚中；（2）当业务遇到单个写热key，需业务拆分这个key的功能，属于设计不合理-当业务遇到热分片，即多个热key在同⼀个分片上导致单分片cpu⾼，可通过hashtag⽅式打散

[引自腾讯云技术分享]

(2) 避免其他问题导致缓存服务器崩溃，进而简直导致数据⼀致性策略失效

缓存穿透、缓存击穿、缓存雪崩、机器故障等问题

(3)方案选定的思路

1. 确定缓存类型（读写/只读）
2. 确定⼀致性级别
3. 确定同步/异步⽅式
4. 选定缓存流程
5. 补充细节