如何保证MySQL和Redis的数据一致性? 原创
存储 存储软件 MySQL 开发工具 Redis
今天给大家剖析一下工作中常见的 MySQL 和 Redis 数据一致性问题。

  

图片来自 包图网

【51CTO.com原创稿件】今天给大家剖析一下工作中常见的 MySQL 和 Redis 数据一致性问题。

什么是数据的一致性

一致性就是数据保持一致,在分布式系统中,可以理解为多个节点中数据的值是一致的。

而一致性又可以分为强一致性与弱一致性。强一致性可以理解为在任意时刻,所有节点中的数据是一样的。

同一时间点,你在节点 A 中获取到的值与在节点 B 中获取到的值应该都是一样的。

弱一致性包含很多种不同的实现,目前分布式系统中广泛实现的是最终一致性。

所谓最终一致性,就是不保证在任意时刻任意节点上的同一份数据都是相同的,但是随着时间的迁移,不同节点上的同一份数据总是在向趋同的方向变化。

也可以简单的理解为在一段时间后,节点间的数据会最终达到一致状态。

当下互联网绝大部分公司都进行了数据库拆分和服务化(SOA)微服务。在这种情况下,完成某一个业务功能可能需要横跨多个服务,操作多个数据库(包含关系型数据库,非关系型数据库)。

这就涉及到需要操作的资源位于多个资源服务器上,而应用需要保证对于多个资源服务器的数据的操作,要么全部成功,要么全部失败,因此我们必须保证不同资源服务器的数据一致性。

那么数据一致性有哪些类型呢?我在这里给他做个具体的分类,让大家实现数据一致性到底在什么场景下需要实现数据一致性。

①跨库数据一致性

库数据量比较大或者预期未来的数据量比较大,都会进行分库分表存储。那就意味着同一个表的数据可能存储在不同库中。此时也存储分布式场景下数据一致性问题。

②微服务拆分

现在互联网企业都使用微服务架构,服务被拆分成很多不同的相互独立的系统,系统之间通过网络进行通信,每一个服务都自己独立的数据库。

例如:某个应用同时操作了多个库,这样的应用业务逻辑必然非常复杂,对于开发人员是极大的挑战,应该拆分成不同的独立服务,以简化业务逻辑。拆分后,独立服务之间通过 RPC 框架来进行远程调用,实现彼此的通信。

此时上图所描述的架构中对应 2 个对应分布式事务处理点:

  • 多个服务之间事务处理(一个服务调用多个服务)
  • 多数据源事务处理(一个服务访问多个数据源)

Service A 完成某个功能需要直接操作数据库,同时需要调用 Service B 和 Service C,而 Service B 又同时操作了 2 个数据库,Service C 也操作了一个库。

需要保证这些跨服务的对多个数据库的操作要不都成功,要不都失败,实际上这可能是最典型的数据一致性场景。

③基于不同类型数据存储

数据一致性另一个场景就是同时操作不同的种类的数据库,但同时还需要满足不同的数据库的数据一致性问题。

缓存数据一致基本上是指:如果缓存中有数据,那么缓存的数据值等于数据库中的值。

但是根据缓存中是有数据为依据,则”一致“可以包含以下的两种情况:

  • 缓存中有数据,那么缓存的数据值等同于数据库中的值(需均为最新值,本文将“旧值的一致”归类为“不一致状态”)。
  • 缓存中本没有数据,那么数据库中的值等同于最新值(有请求查询数据库时,会将数据写入缓存,则变为上面的“一致”状态)。

数据不一致:缓存的数据值不等同于数据库中的值;缓存或者数据库中存在旧值,导致其他线程读到旧数据。

本文将会带大家详细了解一下缓存一致性如何实现,以及缓存一致性的原理是什么样的。

数据不一致情况及应对策略

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

  • 只读缓存:只在缓存进行数据查找,即可以使用 “更新数据库+删除缓存” 策略。
  • 读写缓存:需要在缓存中对数据进行增删改查,即可以使用 “更新数据库+更新缓存”策略。

①针对只读缓存

只读缓存:新增数据时,直接写入数据库;更新(修改/删除)数据时,先删除缓存。

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

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

更新(修改/删除)数据时,会有个时序问题:更新数据库与删除缓存的顺序(这个过程会发生数据不一致性问题)。

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

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

因此,要想达到数据一致性,需要保证两点:

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

接下来,我们针对有/无并发场景,进行分析并使用不同的策略。

②无并发情况

无并发请求下,在更新数据库和删除缓存值的过程中,因为操作被拆分成两步,那么就很有可能存在“步骤 1 成功,步骤 2 失败” 的情况发生。

由于单线程中步骤 1 和步骤 2 是串行执行的,不太可能会发生 “步骤 2 成功,步骤 1 失败” 的情况。

先删除缓存,再更新数据库:

先更新数据库,再删除缓存:

因此,如果先删除缓存,后更新数据库,那么删除缓存成功,更新数据库失败,以致于请求无法命中缓存,读取数据库旧值,存在一致性问题。

如果先更新数据库,后删除缓存,那么更新数据库成功,删除缓存失败,以致于请求命中缓存,读取命中缓存旧值,也存在一致性问题

那么它的解决策略是什么呢?消息队列+异步重试。

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

③高并发情况

使用以上策略后,可以保证在单线程/无并发场景下的数据一致性。但是,在高并发场景下,由于数据库层面的读写并发,会引发的数据库与缓存数据不一致的问题(本质是后发生的读请求先返回了)。

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

假设线程 1 删除缓存值后,由于网络延迟等原因导致未及更新数据库,而此时,线程 2 开始读取数据时会发现缓存缺失,进而去查询数据库。

而当线程 2 从数据库读取完数据、更新了缓存后,线程 1 才开始更新数据库,此时,会导致缓存中的数据是旧值,而数据库中的是最新值,产生“数据不一致”。

其本质就是,本应后发生的“线程 2-读请求” 先于 “线程 1-写请求” 执行并返回了。

那么针对这种问题,我们的解决策略如下所示:

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

此外,还可以通过延时双删进行保障:在线程 1 更新完数据库值以后,让它先 sleep 一小段时间,确保线程 2 能够先从数据库读取数据,再把缺失的数据写入缓存,然后,线程 1 再进行删除。

后续,其它线程读取数据时,发现缓存缺失,会从数据库中读取最新值。

  1. redis.delKey(X) 
  2. db.update(X) 
  3. Thread.sleep(N) 
  4. redis.delKey(X) 

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

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

如果线程 1 更新了数据库中的值,但还没来得及删除缓存值,线程 2 就开始读取数据了,那么此时,线程 2 查询缓存时,发现缓存命中,就会直接从缓存中读取旧值。

其本质也是,本应后发生的“2 线程-读请求” 先于 “1 线程-删除缓存” 执行并返回了。

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

以上问题的解决方案如下所示:

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

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

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

加锁:更新数据时,加写锁;查询数据时,加读锁 保证两步操作的“原子性”,使得操作可以串行执行。“原子性”的本质是什么?不可分割只是外在表现,其本质是多个资源间有一致性的要求,操作的中间状态对外不可见。

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

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

④针对读写缓存

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

同步直写:使用事务,保证缓存和数据更新的原子性,并进行失败重试(如果 Redis 本身出现故障,会降低服务的性能和可用性)。

异步回写:写缓存时不同步写数据库,等到数据从缓存中淘汰时,再写回数据库(没写回数据库前,缓存发生故障,会造成数据丢失) 该策略在秒杀场中有见到过,业务层直接对缓存中的秒杀商品库存信息进行操作,一段时间后再回写数据库。

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

无并发情况:

高并发情况,有四种场景会造成数据不一致:

针对场景 1 和 2 的解决方案是:保存请求对缓存的读取记录,延时消息比较,发现不一致后,做业务补偿。

针对场景 3 和 4 的解决方案是:对于写请求,需要配合分布式锁使用。

写请求进来时,针对同一个资源的修改操作,先加分布式锁,保证同一时间只有一个线程去更新数据库和缓存;没有拿到锁的线程把操作放入到队列中,延时处理。用这种方式保证多个线程操作同一资源的顺序性,以此保证一致性。

其中,分布式锁的实现可以使用以下策略:

  • 乐观锁:使用版本号、updatetime;缓存中只容许高版本覆盖低版本。
  • Watch 实现 Redis 乐观锁:Watch 监控 Rediskey 的状态值,创建 Redis 事务,key+1,执行事务,key 被修改过则回滚。
  • Setnx:获取锁:set/setnx;释放锁:del/lua。

Redisson 分布式锁:利用 Redis 的 hash 结构作为储存单元,将业务指定的名称作为 key,将随机 UUID 和线程 ID 作为 fleld,最后将加锁的次数作为 value 来储存,线程安全。

⑤强一致性策略

上述策略只能保证数据的最终一致性。要想做到强一致,最常见的方案是 2PC、3PC、Paxos、Raft 这类一致性协议,但它们的性能往往比较差,而且这些方案也比较复杂,还要考虑各种容错问题。

如果业务层要求必须读取数据的强一致性,可以采取以下策略:

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

串行化:读写请求入队列,工作线程从队列中取任务来依次执行,修改服务 Service 连接池,id 取模选取服务连接,能够保证同一个数据的读写都落在同一个后端服务上。

修改数据库 DB 连接池,id 取模选取 DB 连接,能够保证同一个数据的读写在数据库层面是串行的。

使用 Redis 分布式读写锁:将淘汰缓存与更新库表放入同一把写锁中,与其他读请求互斥,防止其间产生旧数据。

读写互斥、写写互斥、读读共享,可满足读多写少的场景数据一致,也保证了并发性。并根据逻辑平均运行时间、响应超时时间来确定过期时间。

作者:JackHu

简介:水滴健康基础架构资深技术专家

编辑:陶家龙

征稿:有投稿、寻求报道意向技术人请联络 editor@51cto.com

【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】

 

责任编辑:武晓燕 来源: 51CTO技术栈

同话题下的热门内容

技术大比武:让每一个人都是一道光,不断突破与成长

编辑推荐

再谈Raid 5和Raid 6的写性能差异ECC内存和普通内存有什么区别,有必要买ECC内存吗云存储技术的原理是什么?百度网盘技术原理分析分布式存储与传统SAN、NAS相比,有什么优势与劣势?Redis内存淘汰策略,看这一篇就够了!
我收藏的内容
点赞
收藏

51CTO技术栈视频号