如何保证MySQL和Redis的数据分歧性

图片来自 包图网

当天给大家剖析一下上班中经常出现的 MySQL 和 Redis 数据分歧性疑问。

什么是数据的分歧性

分歧性就是数据坚持分歧，在散布式系统中，可以了解为多个节点中数据的值是分歧的。

而分歧性又可以分为强分歧性与弱分歧性。强分歧性可以了解为在恣意时辰，一切节点中的数据是一样的。

同一期间点，你在节点 A 中失掉到的值与在节点 B 中失掉到的值应该都是一样的。

弱分歧性蕴含很多种不同的成功，目前散布式系统中宽泛成功的是最终分歧性。

所谓最终分歧性，就是不保证在恣意时辰恣意节点上的同一份数据都是相反的，然而随着期间的迁徙，不同节点上的同一份数据总是在向趋同的方向变化。

也可以便捷的了解为在一段期间后，节点间的数据会最终到达分歧形态。

当下互联网绝大局部公司都启动了数据库拆分和服务化(SOA)微服务。在这种状况下，成功某一个业务配置或许须要横跨多个服务，操作多个数据库(蕴含相关型数据库，非相关型数据库)。

这就触及到须要操作的资源位于多个资源主机上，而运行须要保证关于多个资源主机的数据的操作，要么所有成功，要么所有失败，因此我们肯定保证不同资源主机的数据分歧性。

那么数据分歧性有哪些类型呢?我在这里给他做个详细的分类，让大家成功数据分歧性究竟在什么场景下须要成功数据分歧性。

①跨库数据分歧性

库数据量比拟大或许预期未来的数据量比拟大，都会启动分库分表存储。那就象征着同一个表的数据或许存储在不同库中。此时也存储散布式场景下数据分歧性疑问。

②微服务拆分

如今互联网企业都经常使用微服务架构，服务被拆分红很多不同的相互独立的系统，系统之间经过网络启动通讯，每一个服务都自己独立的数据库。

例如：某个运行同时操作了多个库，这样的运行业务逻辑肯定十分复杂，关于开发人员是极大的应战，应该拆分红不同的独立服务，以简化业务逻辑。拆分后，独立服务之间经过 RPC 框架来启动远程调用，成功彼此的通讯。

此时上图所形容的架构中对应 2 个对应散布式事务处置点：

Service A 成功某个配置须要间接操作数据库，同时须要调用 Service B 和 Service C，而 Service B 又同时操作了 2 个数据库，Service C 也操作了一个库。

须要保证这些跨服务的对多个数据库的操作要不都成功，要不都失败，实践上这或许是最典型的数据分歧性场景。

③基于不同类型数据存储

数据分歧性另一个场景就是同时操作不同的种类的数据库，但同时还须要满足不同的数据库的数据分歧性疑问。

缓存数据分歧基本上是指：假设缓存中有数据，那么缓存的数据值等于数据库中的值。

然而依据缓存中是有数据为依据，则”分歧“可以蕴含以下的两种状况：

数据不分歧：缓存的数据值不同等于数据库中的值;缓存或许数据库中存在旧值，造成其余线程读到旧数据。

本文将会带大家详细了解一下缓存分歧性如何成功，以及缓存分歧性的原理是什么样的。

数据不分歧状况及应答战略

依据能否接纳写恳求，可以把缓存分红读写缓存和只读缓存：

①针对只读缓存

只读缓存：新增数据时，间接写入数据库;降级(修正/删除)数据时，先删除缓存。

后续，访问这些增删改的数据时，会出现缓存缺失，进而查问数据库，降级缓存。

新增数据时，写入数据库;访问数据时，缓存缺失，查数据库，降级缓存(一直是处于”数据分歧“的形态，不会出现数据不分歧性疑问)。

降级(修正/删除)数据时，会有个时序疑问：降级数据库与删除缓存的顺序(这个环节会出现数据不分歧性疑问)。

在降级数据的环节中，或许会有如下疑问：

因此，要想到达数据分歧性，须要保证两点：

接上去，我们针对有/无并发场景，启动剖析并经常使用不同的战略。

②无并发状况

无并发恳求下，在降级数据库和删除缓存值的环节中，由于操作被拆分红两步，那么就很有或许存在“步骤 1 成功，步骤 2 失败” 的状况出现。

由于复线程中步骤 1 和步骤 2 是串行口头的，不太或许会出现 “步骤 2 成功，步骤 1 失败” 的状况。

先删除缓存，再降级数据库：

先降级数据库，再删除缓存：

因此，假设先删除缓存，后降级数据库，那么删除缓存成功，降级数据库失败，致使于恳求无法命中缓存，读取数据库旧值，存在分歧性疑问。

假设先降级数据库，后删除缓存，那么降级数据库成功，删除缓存失败，致使于恳求命中缓存，读取命中缓存旧值，也存在分歧性疑问

那么它的处置战略是什么呢?信息队列+异步重试。

无论经常使用哪一种口头时序，可以在口头步骤 1 时，将步骤 2 的恳求写入信息队列，当步骤 2 失败时，就可以经常使用重试战略，对失败操作启动 “补救”。

③高并发状况

经常使用以好方法略后，可以保证在复线程/无并发场景下的数据分歧性。然而，在高并发场景下，由于数据库层面的读写并发，会引发的数据库与缓存数据不分歧的疑问(实质是后出现的读恳求先前往了)。

(1) 先删除缓存，再降级数据库

假定线程 1 删除缓存值后，由于网络提前等要素造成未及降级数据库，而此时，线程 2 开局读取数据时会发现缓存缺失，进而去查问数据库。

而当线程 2 从数据库读取完数据、降级了缓存后，线程 1 才开局降级数据库，此时，会造成缓存中的数据是旧值，而数据库中的是最新值，发生“数据不分歧”。

其实质就是，本应后出现的“线程 2-读恳求” 先于 “线程 1-写恳求” 口头并前往了。

那么针对这种疑问，我们的处置战略如下所示：

设置缓存过时期间 + 延时双删：经过设置缓存过时期间，若出现上述淘汰缓存失败的状况，则在缓存过时后，读恳求依然可以从 DB 中读取最新数据并降级缓存，可减小数据不分歧的影响范畴。只管在肯定期间范畴内数据有差异，但可以保证数据的最终分歧性。

此外，还可以经过延时双删启动保证：在线程 1 降级完数据库值，让它先 sleep 一小段期间，确保线程 2 能够先从数据库读取数据，再把缺失的数据写入缓存，而后，线程 1 再启动删除。

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

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

sleep 在业务程序运转的时刻，统计下线程读数据和写缓存的操作期间，以此为基础来启动预算。

(2) 先降级数据库，再删除缓存

假设线程 1 降级了数据库中的值，但还没来得及删除缓存值，线程 2 就开局读取数据了，那么此时，线程 2 查问缓存时，发现缓存命中，就会间接从缓存中读取旧值。

其实质也是，本应后出现的“2 线程-读恳求” 先于 “1 线程-删除缓存” 口头并前往了。

或许，在”先降级数据库，再删除缓存”打算下，“读写分别+主从库提前”也会造成不分歧。

以上疑问的处置打算如下所示：

提前信息：仰仗阅历发送「提前信息」到队列中，提前删除缓存，同时也要控制主从库提前，尽或许降落不分歧出现的概率。

订阅 binlog，异步删除：经过数据库的 binlog 来异步淘汰 key，应用工具(canal)将 binlog 日志采集发送到 MQ 中，而后经过 ACK 机制确认处置删除缓存。

删除信息写入数据库：经过比对数据库中的数据，启动删除确认 先降级数据库再删除缓存，有或许造成恳求因缓存缺失而访问数据库，给数据库带来压力，也就是缓存穿透的疑问。针对缓存穿透疑问，可以用缓存空结果、布隆过滤器启动处置。

加锁：降级数据时，加写锁;查问数据时，加读锁 保证两步操作的“原子性”，使得操作可以串行口头。“原子性”的实质是什么?无法宰割只是内在体现，其实质是多个资源间有分歧性的要求，操作的两边形态对外无法见。

倡导，优先经常使用“先降级数据库再删除缓存”的口头时序，要素重要有两个：

④针对读写缓存

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

同步直写：经常使用事务，保证缓存和数据降级的原子性，并启动失败重试(假设 Redis 自身出现缺点，会降落服务的性能和可用性)。

异步回写：写缓存时不同步写数据库，等到数据从缓存中淘汰时，再写回数据库(没写回数据库前，缓存出现缺点，会形成数据失落) 该战略在秒杀场中有见到过，业务层间接对缓存中的秒杀商品库存信息启动操作，一段期间后再回写数据库。

分歧性：同步直写>异步回写，因此，关于读写缓存，要坚持数据强分歧性的重要思绪是：应用同步直写，同步直写也存在两个操作的时序疑问：降级数据库和降级缓存。

无并发状况：

高并发状况，有四种场景会形成数据不分歧：

针对场景 1 和 2 的处置打算是：保留恳求对缓存的读取记载，延时信息比拟，发现不分歧后，做业务补救。

针对场景 3 和 4 的处置打算是：关于写恳求，须要配合散布式锁经常使用。

写恳求出去时，针对同一个资源的修正操作，先加散布式锁，保证同一期间只要一个线程去降级数据库缓和存;没有拿到锁的线程把操作放入到队列中，延时处置。用这种模式保证多个线程操作同一资源的顺序性，以此保证分歧性。

其中，散布式锁的成功可以经常使用以下战略：

Redisson 散布式锁：应用 Redis 的 hash 结构作为贮存单元，将业务指定的称号作为 key，将随机 UUID 和线程 ID 作为 fleld，最后将加锁的次数作为 value 来贮存，线程安保。

⑤强分歧性战略

上述战略只能保证数据的最终分歧性。要想做到强分歧，最经常出现的打算是 2PC、3PC、Paxos、Raft 这类分歧性协定，但它们的性能往往比拟差，而且这些打算也比拟复杂，还要思考各种容错疑问。

假设业务层要求肯定读取数据的强分歧性，可以采取以下战略：

暂存并发读恳求：在降级数据库时，先在 Redis 缓存客户端暂存并发读恳求，等数据库降级完、缓存值删除后，再读取数据，从而保证数据分歧性。

串行化：读写恳求入队列，上班线程从队列中取义务来依次口头，修正服务 Service 衔接池，id 取模选取服务衔接，能够保证同一个数据的读写都落在同一个后端服务上。

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

经常使用 Redis 散布式读写锁：将淘汰缓存与降级库表放入同一把写锁中，与其余读恳求互斥，防止其间发生旧数据。

读写互斥、写写互斥、读读共享，可满足读多写少的场景数据分歧，也保证了并发性。并依据逻辑平均运转期间、照应超时期间来确定过时期间。

作者：JackHu

简介：水滴肥壮基础架构资深技术专家

编辑：陶家龙