Mysql数据的一致性 mysql数据一致性问题

目录

• 一致性定义
• 一致性解决方法

• 1. 缓存形式
• 2. 只读缓存

• 2.1. 新增数据
• 2.2. 更新（修改/删除）数据

• 2.2.1. 无并发环境

• 2.2.1.1. 消息队列+异步重试
• 2.2.1.2. 订阅 Binlog 变更日志

• 2.2.2. 高并发环境

• 2.2.2.1. 先删除缓存，再更新DB
• 2.2.2.2. 缓存过期时间+延时双删
• 2.2.2.3. 先更新DB，再删除缓存
• 2.2.2.4. 延迟消息
• 2.2.2.5. 订阅 binlog，异步删除
• 2.2.2.6. 删除消息写入数据库
• 2.2.2.7. 加锁

• 3. 读写缓存

• 3.1. 无并发环境
• 3.2. 高并发环境

• 4. 强一致性策略
• 5. 小结

• 5.1. 缓存小结
• 5.2. 数据一致性解决方法

• 其他问题

• 1. k-v相关
• 2. 防止缓存崩溃

• 2.1. 缓存穿透
• 2.2. 缓存击穿
• 2.3. 缓存雪崩

• 3. 方案选型的思路

一致性定义

一致性的前提是有数据，而数据根据不同的要求会有各种形式的存储方式，各存储方式下的数据都统一，则成为数据一致性。

因此数据一致一般指的是：缓存中有数据，缓存的数据值=数据库中的值。

数据一致：

• 缓存中有数据，缓存的数据值 = 数据库中的值（需均为最新值，本文将“旧值的一致”归类为“不一致状态”）
• 缓存中无数据，数据库中的值 = 最新值（有请求查询数据库时，会将数据写入缓存，则变为上面的“一致”状态）

数据不一致：

• 缓存的数据值 ≠ 数据库中的值
• 缓存或者数据库中存在旧值，导致其他线程读到旧数据

一致性解决方法

1. 缓存形式

• 只读缓存： 不接受写请求，只在缓存进行数据查找， “更新DB+删除缓存”
• 读写缓存：接受写请求，在缓存中对数据进行增删改查， “更新DB、缓存”

2. 只读缓存

策略： 新增数据时，直接写入数据库；更新（修改/删除）数据时，先删除缓存（后续访问这些增删改的数据时，会发生缓存缺失，进而查询数据库，更新缓存）。

2.1. 新增数据

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

2.2. 更新（修改/删除）数据

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

存在问题：

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

解决方法：

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

2.2.1. 无并发环境

串行化执行：将更新数据库的操作划分为 更新数据库 和 删除缓存值 两个步骤，分别执行。

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

可能会出现删除缓存成功，更新数据库失败的情况，无法命中缓存，读取到DB中的旧值，造成数据一致性问题。

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

可能会出现更新DB成功，删除缓存失败的情况，命中缓存但读取了旧值，造成数据一致性问题。

2.2.1.1. 消息队列+异步重试

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

具体步骤如下：

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

2.2.1.2. 订阅 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 中的数据不一致。
因此，使用这种策略时，需要考虑出现不同步问题时的降级或补偿方案。

2.2.2. 高并发环境

本质：本应后发生的“B 线程-读请求” 先于 “A 线程-写请求” 执行并返回

2.2.2.1. 先删除缓存，再更新DB

或

造成线程B获取到旧值，且缓存与DB数据不一致的问题。

2.2.2.2. 缓存过期时间+延时双删

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

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

// 删除缓存
redis.delKey(X)
// 更新DB
db.update(X)
// 睡眠，时间：在业务程序运行的时候，统计下线程读数据和写缓存的操作时间，以此为基础来进行估算
Thread.sleep(N)
// 双删，再次删除
redis.delKey(X)

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

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

2.2.2.3. 先更新DB，再删除缓存

或读写分离+主从库延迟情况下

2.2.2.4. 延迟消息

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

2.2.2.5. 订阅 binlog，异步删除

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

2.2.2.6. 删除消息写入数据库

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

2.2.2.7. 加锁

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

保证两步操作的“原子性”，使得操作可以串行执行。

原子性：不可分割只是外在表现，其本质是多个资源间有一致性的要求，操作的中间状态对外不可见。

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

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

3. 读写缓存

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

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

一致性：同步直写 > 异步回写
因此，对于读写缓存，要保持数据强一致性的主要思路是：利用同步直写
同步直写也存在两个操作的时序问题：更新数据库和更新缓存

3.1. 无并发环境

执行顺序	潜在问题	结果	解决策略
先更新缓存，后更新DB	更新DB失败	DB为旧值	消息队列+重试机制
先更新DB，后更新缓存	更新缓存失败	缓存为旧值	消息队列+重试机制 订阅Binlog日志

3.2. 高并发环境

造成数据一致性问题的四种场景

执行顺序	并发类型	具体步骤	影响程度	解决方案
先更新DB 后更新缓存	写+读	1、线程A先更新DB 2、线程B命中缓存读旧值 3、线程A更新缓存	更新DB和缓存期间读请求会返回旧值 短暂影响业务	保存对缓存的读取请求 通过延时消息比较做业务修正
先更新DB 后更新缓存	写+写	1、线程A与B同时更新数据 2、更新DB顺序先A后B 3、更新缓存顺序先B后A	造成DB与缓存数据不一致，影响较大	分布式锁+延时处理队列 确保同一时间只有一个写线程
先更新缓存 后更新DB	写+读	1、线程A先更新缓存 2、线程B命中缓存读新值 3、线程A更新DB	更新缓存和DB期间有短暂的数据一致性问题 但能返回最新值，对业务影响较小	保存对缓存的读取请求 通过延时消息比较做业务修正
先更新缓存 后更新DB	写+写	1、线程A与B同时更新数据 2、更新缓存顺序先A后B 3、更新DB顺序先B后A	造成DB与缓存数据不一致，影响较大	分布式锁+延时处理队列 确保同一时间只有一个写线程

分布式锁策略

4. 强一致性策略

上述策略只能保证数据的最终一致性。要想做到强一致，最常见的方案是 2PC、3PC、Paxos、Raft 这类一致性协议，但它们的性能往往比较差，而且这些方案也比较复杂，还要考虑各种容错问题。
如果业务层要求必须读取数据的强一致性，可以采取以下策略：

（1）暂存并发读请求

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

（2）串行化

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

• 修改服务 Service 连接池，id 取模选取服务连接，能够保证同一个数据的读写都落在同一个后端服务上
• 修改数据库 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);
}

5. 小结

5.1. 缓存小结

缓存类型	策略	优点	缺点	适用场景
读写缓存	更新DB+更新缓存	缓存中会一直有数据，可以保证缓存 的命中率，缓解对于DB的压力	如果缓存更新后很少使用，会导致缓存 利用率不高，浪费资源	读写相当
只读缓存	更新DB+删除缓存	缓存中保存的都是热数据 缓存利用率高	删除缓存会导致缓存缺失 以及再加载的过程，对DB压力较大	读多写少

5.2. 数据一致性解决方法

针对读写缓存时：同步直写，更新数据库+更新缓存：
（1）先更新DB，再更新缓存

并发情况	潜在问题	结果	应对方案
无并发	更新DB成功，更新缓存失败	从缓存中读到旧值	重试缓存更新
写+读	线程A更新缓存前，线程B会从缓存读到旧值	从缓存中短暂读到旧值	保存缓存读取记录，后做补偿
写+写	线程A、B对于DB、缓存的修改顺序不同	DB与缓存的数据不一致	添加分布式锁

（2）先更新缓存，再更新DB

并发情况	潜在问题	结果	应对方案
无并发	更新缓存成功，更新DB失败	数据库存在旧值	重试DB更新
写+读	线程A更新DB前，线程B会从缓存读到新值	短暂存在数据不一致，不影响业务	MQ确认DB更新成功
写+写	线程A、B对于DB、缓存的修改顺序不同	DB与缓存的数据不一致	添加分布式锁

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

（1）先更新DB，再删除缓存

并发情况	潜在问题	结果	应对方案
无并发	DB更新成功，缓存删除失败	命中缓存，读取旧值	重试缓存删除
有并发	尚未删除缓存，有并发请求	命中缓存，读取旧值	延迟消息、订阅Binlog变更日志、加分布式锁

（2）先删除缓存，再更新DB

并发情况	潜在问题	结果	应对方案
无并发	缓存删除成功，更新DB失败	数据库存在旧值	重试DB更新
有并发	尚未更新DB，有并发请求	从DB中读到旧值，且将旧值重新写入缓存	延迟双删、加分布式锁

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

• 在并发场景下，使用 “更新数据库 + 更新缓存” 需要用分布式锁保证缓存和数据一致性，且可能存在”缓存资源浪费“和”机器性能浪费“的情况。一般推荐使用 “更新数据库 + 删除缓存” 的方案。如果根据需要，热点数据较多，可以使用 “更新数据库 + 更新缓存” 策略。
• 在 “更新数据库 + 删除缓存” 的方案中，推荐使用推荐用 “先更新数据库，再删除缓存” 策略，因为先删除缓存可能会导致大量请求落到数据库，而且延迟双删的时间很难评估。在 “先更新数据库，再删除缓存” 策略中，可以使用“消息队列+重试机制” 的方案保证缓存的删除。并通过 “订阅 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. 防止缓存崩溃

2.1. 缓存穿透

缓存穿透：当查询一个不存在的数据时，无法命中缓存导致每次都需要到DB中获取数据，导致DB崩溃。

解决方案：

（1）查询返回的数据为空，仍把这个空结果加入缓存，但过期时间设置得短一些；

（2）布隆过滤器，将所有可能存在得数据hash到一个足够大的bitmap中，将一定不会出现的数据通过bitmap过滤掉；

2.2. 缓存击穿

缓存击穿：对于设置了过期时间的key，当某个时间节点缓存过期后，有大量的并发请求这个key，瞬间将DB压垮。

解决方案：

（1）使用互斥锁，当缓存失效时，先用Redis的setnx去设置一个互斥锁，当操作成功返回时再进行数据库操作并回设缓存，，否则重试get缓存的方法；

（2）永不过期，逻辑会过期但是物理不过期，后台异步线程刷新；

2.3. 缓存雪崩

缓存雪崩：设置缓存时采用了相同的过期时间，缓存在某一时刻同时消失时，导致大量的请求无法命中缓存，去访问数据库。

解决方案：

（1）分散缓存失效的时间，在原有的设置逻辑上新增一个时间偏移；

（2）使用互斥锁，当缓存数据失效时，保证只有一个请求能够访问到数据库，并更新缓存，其他线程等待重试；

3. 方案选型的思路

（1）确定缓存类型（读写/只读）

（2）确定一致性级别

（3）确定同步/异步方式

（4）选定缓存流程