如何保证Redis双写一致性？

2024-04-30 18:12
文章标签 redis 一致性 保证 双写

本文主要是介绍如何保证Redis双写一致性？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

目录

数据不一致问题

数据库和缓存不一致解决方案

1. 先更新缓存，再更新数据

该方案数据不一致的原因

2. 先更新数据库，再更新缓存

3. 先删除缓存，再更新数据库

延时双删

4. 先更新数据库，再删除缓存

该方案数据不一致的场景和解决办法

缓存删除失败，该如何处理？

MQ异步重试删除

监控binlog删除

面试中关于Redis双写一致性，如何应答？

如何实现强一致性？

在数据库层和客户端层添加一层缓存，可以提高用户的访问性能。

比如一些商品秒杀业务，这时并发量高，要是所有请求都是打到数据库层(用MySQL举例),那用户的体验可能就不太好，因为操作数据库是要操作磁盘，性能比较低。而中间加一层缓存(用Redis举例），把数据存储在Redis中。Redis是基于内存的，操作速度极快，那并发量就可以提高了。

数据不一致问题

那就会引出问题，出现Redis和MySQL的数据不一致问题。由于缓存和数据库是分开的，无法做到原子性的同时进行数据修改，可能出现缓存更新失败，或者数据库更新失败的情况，这时候会出现数据不一致，影响业务。

数据库和缓存不一致解决方案

大方向有三种：

  • Cache Aside Pattern 旁路缓存模式，也叫人工编码方式：需要程序员写代码 同时维系 DB 和 cache。也称作双写方案。
  • Read/Write Through Pattern：缓存与数据库整合为一个服务，由服务来维护一致性。调用者调用该服务，无需关系缓存一致性问题。但是维护这样一个服务很复杂，市面上也不容易找到一个这样现成的服务，开发成本高。
  • Write Behind Caching Pattern：调用者只操作缓存，其他线程异步去处理数据库，最终实现一致性。但是维护这样的一个异步任务比较复杂，需要实时监控缓存中的数据更新，而其他线程异步去更新数据库也可能不太及时，而且缓存服务器如果宕机，那么缓存的数据也就丢失了。

综上所述，在企业的实际应用中，还是Cache Aside Pattern方案最可靠。现在确定了该方案，但是需要程序员去调用缓存和数据库？那因为是两个应用，那操作就有先后顺序，那是应该先操作哪个呢？还有是更新缓存还是删除缓存呢？

可以分成4种情况：

  • 先更新缓存，再更新数据
  • 先更新数据库，再更新缓存
  • 先删除缓存，再更新数据库
  • 先更新数据库，再删除缓存

现在来逐个分析下其优缺点和是否可用。 

1. 先更新缓存，再更新数据

 首先给结论——该方案不可行。

场景1：事务问题导致数据不一致

在MySQL写入或者其他业务逻辑出现异常错误时候，MySQL会进行回滚，那MySQL中数据会变回100，而Redis就会更新为100，这就出现了数据不一致问题。

这个就是因为Redis和MySQL两个数据库写操作不具备事务的ACID特性，无法保证这两个写操作的原子性。

发生该问题的场景有如下两个：

  • 修改Redis成功，修改MySQL失败，而Redis不会回滚
  • 整个过程其他业务逻辑出现异常，MySQL会回滚，而Redis却不会回滚。

场景2：多并发更新

上图所示，线程1修改Redis数据，之后线程2抢占了cpu时间，那MySQL最终结果是200，就和Redis的数据不一致。这就是线程并发导致数据覆盖，造成数据不一致。

所以，先更新缓存，再更新数据库这种方法不可行。

该方案数据不一致的原因

  • 不同数据库之间双写不具备事务原子性，造成数据不一致
  • 线程并发导致数据覆盖，造成数据不一致

2. 先更新数据库，再更新缓存

 首先给结论——该方案不可行。

原因和先更新缓存，再更新数据库是一样的。

场景1：修改账户余额，整个过程其他业务逻辑出现异常，MySQL进行回滚，而Redis却不会回滚。

场景二：多线程并发更新用户账户余额

 

 也是因为并发，线程1修改数据库后，线程2抢占了cpu时间，最终导致结果不一致。

所以先更新数据库，再更新缓存 也不行。

两点原因：

  • 不同数据库之间双写不具备事务原子性，造成数据不一致
  • 线程并发导致数据覆盖，造成数据不一致

3. 先删除缓存，再更新数据库

场景：多线程并发更新用户余额

上图的情况①、②、③都不会导致数据不一致，而情况④会导致数据不一致。线程1在Redis中删除，之后线程2抢占cpu时间，去查询Redis,而Redis数据是空，那就需要去查询MySQL 。导致了最终Mysql数据是200，而Redis为100。

那使用这个方法，还有什么其他策略可以修复情况④吗？也是可以的，这个就是延时双删。

延时双删

在线程1更新完数据库后，再次删除Redis中的数据，目的是为了清楚缓存中的脏数据。那么，对这个删除执行的时刻是有要求的，不能在线程2修改前执行，一般其时长是要大于一次业务查询时间，所以这个就是延时双删。

其实这个时长不好掌控，有时有些业务的查询时间可长可短。

4. 先更新数据库，再删除缓存

情况①是正常的。情况②出现了短暂的数据不一致问题，那这个就需要业务可以接受。

情况③就出现了较长时间的数据不一致情况。

那其是在什么情况出现的呢？要满足下面两个条件，其效率是很低的

  1. 在读写并发时候，缓存刚好失效，
  2. 且数据库查询耗时远大于更新耗时

所以，先更新数据库，再删除缓存 方案可用。但是要允许读写并发场景下出现短暂不一致情况，和极端情况下产生的数据不一致情况，但是数据是最终一致的。

该方案数据不一致的场景和解决办法

  • 并发读写情况下产生的短暂不一致场景，业务场景要能接受。
  • 并发读写情况下，缓存正好失效且读操作耗时大于写操作而产生的数据不一致。可以通过延时删除，或者给redis设置较短的存活时间。

缓存删除失败，该如何处理？

 MySQL更新失败可以回滚，而Redis删除失败，却不会回滚。那该如何处理缓存删除失败的情况呢？

MQ异步重试删除

其优点就是实现简单，容易理解。

缺点就是添加了个组件，那整个系统的可用性又要维护多一个组件；并且耦合度比较高，那每次使用Redis时候，都需要写判断是否成功，不成功就抛给mq的代码。

监控binlog删除

 其优点：实现了缓存删除的业务解耦

缺点：实现是比较复杂的。

面试中关于Redis双写一致性，如何应答？

分成4步：

  1. 摆方案：保证Redis与MySQL数据库的双写一致性，大方向有三种方案：Cache Aside Pattern 旁路缓存模式、Read/Write Through Pattern缓存与数据库整合为一个服务、Write Behind Caching Pattern。而企业中大多数是使用Cache Aside Pattern：查询的时候，优先从缓存中查，缓存中没有数据再从数据库中查，然后把数据库中的最新值写入到缓存中，保证了数据一致性。
    1. ● 该模式有四种方案：①先更新缓存，再更新数据库、②先更新数据，再更新缓存、③先删除缓存，再更新数据库、④先更新数据，再删除缓存。
  2. 排除不合理的方案:两种双更新的方案不可用，原因有两个：
    1. 第一是因为我们不能保证两个数据库之间写操作的事务原子性，所以可能有一个成功一个失败，造成数据不一致。
    2. 第二是因为并发写操作会造成数据的覆盖，导致数据不一致。
  3. 列可用方案，阐述注意事项：目前常用的，但是这两个问题对于很多业务场景都可以容忍的方案有两个。
    1. 先删除缓存，再更新数据库：该方案理想情况下是没有问题的。但还是有一个特殊场景是有可能出现数据不一致，具体来讲是在发生并发读写时，线程A先删除了缓存，还没来得及更新数据库，线程B此时来查询缓存为空，于是查询到了数据库的旧值，而后将缓存修改成了旧值，解决方案就是采用延时双删，在线程A更新完数据库后延时一段时间再删除缓存，合理的延长时长需要更具业务而定，通常为一次查询业务的耗时。
    2. 先更新数据库，再删除缓存：该方案在理想情况下，也是没有问题的。但是该方案有两个特殊场景是有可能出现数据不一致问题的，第一种是由于并发读写导致的短暂不一致，但是最终数据一致。第二种场景出现几率很低，要求并发读写时缓存正好失效，且数据库查询耗时远远大于更新耗时才有可能发生数据不一致，这个当然也是可以通过延时双删或者给Redis数据设置较短的存活时间来达到最终一致。
    3. 对比这两个方案，最终还是使用先更新数据库，再删除缓存。
  4. 补充如何保证缓存成功删除：之前两种方案都是通过删除缓存来保证双写一致性的，要是缓存删除失败会导致缓存中都是脏数据，所以必须保证缓存删除成功，方案有两种：
    1. 第一种：使用MQ异步重试删除，比较简单，缺点是会对业务代码产生入侵，耦合度比较高。
    2. 第二种：使用阿里的canal模拟MySQL的从库，监听主库的binlog,当数据库发生变更，canal可以监听到并通知客户端去删除缓存，其优点是对业务代码没有入侵性，进行了解耦。

如何实现强一致性？

​ 最终我们还有一个问题没有解决：不论是以上介绍的哪种方案，都会出现数据不一致性，只是出现这个问题的时间长短不同或者是出现的概率高低不同。

​仔细想想，我们加入缓存的初衷是什么，不就是提高吞吐量，获得更高的性能嘛。作为开发者，应该都知道一个非常著名的三角悖论（CAP定理），即对于一个分布式计算系统来说，不可能同时满足以下三点：

  1. ​一致性（Consistency) 所有节点在同一时间具有相同的数据
  2. ​可用性（Availability）保证每个请求不管成功或者失败都有响应
  3. ​分区容错性（Partition tolerance）系统中任意信息的丢失或失败不会影响系统的继续运作

在分布式系统内，P 是必然需要的。不选 P，一旦发生分区错误，整个分布式系统就完全无法使用了，这是不符合实际需要的。所以，对于分布式系统，我们只能考虑当发生分区错误时，如何选择一致性和可用性。即只能从CP、AP中选择。既然选择了高性能和高吞吐量，所以我们只能满足AP。由此也可明白，以上介绍的所有方案都是为了保证将不一致性尽可能的降低，都是保证最终一致性。

如果一定要强一致性，就是不加入缓存；或者使用分布式锁或者读写锁来锁住一次更新数据库和缓存的操作，那这样吞吐量，性能有会下载，可能是得不偿失。

这篇关于如何保证Redis双写一致性？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/949567。

相关文章

零基础学习Redis(10) -- zset类型命令使用

零基础学习Redis(10) -- zset类型命令使用

zset是有序集合，内部除了存储元素外，还会存储一个score，存储在zset中的元素会按照score的大小升序排列，不同元素的score可以重复，score相同的元素会按照元素的字典序排列。 1. zset常用命令 1.1 zadd  zadd key [NX | XX] [GT | LT]   [CH] [INCR] score member [score member ...]
阅读更多...
Redis中使用布隆过滤器解决缓存穿透问题

Redis中使用布隆过滤器解决缓存穿透问题

一、缓存穿透(失效)问题 缓存穿透是指查询一个一定不存在的数据，由于缓存中没有命中，会去数据库中查询，而数据库中也没有该数据，并且每次查询都不会命中缓存，从而每次请求都直接打到了数据库上，这会给数据库带来巨大压力。 二、布隆过滤器原理 布隆过滤器（Bloom Filter）是一种空间效率很高的随机数据结构，它利用多个不同的哈希函数将一个元素映射到一个位数组中的多个位置，并将这些位置的值置
阅读更多...
Lua 脚本在 Redis 中执行时的原子性以及与redis的事务的区别

Lua 脚本在 Redis 中执行时的原子性以及与redis的事务的区别

在 Redis 中，Lua 脚本具有原子性是因为 Redis 保证在执行脚本时，脚本中的所有操作都会被当作一个不可分割的整体。具体来说，Redis 使用单线程的执行模型来处理命令，因此当 Lua 脚本在 Redis 中执行时，不会有其他命令打断脚本的执行过程。脚本中的所有操作都将连续执行，直到脚本执行完成后，Redis 才会继续处理其他客户端的请求。 Lua 脚本在 Redis 中原子性的原因
阅读更多...
MySQL中一致性非锁定读

MySQL中一致性非锁定读

一致性非锁定读(consistent nonlocking read)是指InnoDB存储引擎通过多版本控制(multi versionning)的方式来读取当前执行时间数据库中行的数据，如果读取的行正在执行DELETE或UPDATE操作，这是读取操作不会因此等待行上锁的释放。相反的，InnoDB会去读取行的一个快照数据 上面展示了InnoDB存储引擎一致性的非锁定读。之所以称为非锁定读，因
阅读更多...
InnoDB的多版本一致性读的实现

InnoDB的多版本一致性读的实现

InnoDB是支持MVCC多版本一致性读的，因此和其他实现了MVCC的系统如Oracle，PostgreSQL一样，读不会阻塞写，写也不会阻塞读。虽然同样是MVCC，各家的实现是不太一样的。Oracle通过在block头部的事务列表，和记录中的锁标志位，加上回滚段，个人认为实现上是最优雅的方式。 而PostgreSQL则更是将多个版本的数据都放在表中，而没有单独的回滚段，导致的一个结果是回滚非
阅读更多...
PHP: 深入了解一致性哈希

PHP: 深入了解一致性哈希

前言 随着memcache、redis以及其它一些内存K/V数据库的流行，一致性哈希也越来越被开发者所了解。因为这些内存K/V数据库大多不提供分布式支持(本文以redis为例)，所以如果要提供多台redis server来提供服务的话，就需要解决如何将数据分散到redis server，并且在增减redis server时如何最大化的不令数据重新分布，这将是本文讨论的范畴。 取模算法 取模运
阅读更多...
laravel框架实现redis分布式集群原理

laravel框架实现redis分布式集群原理

在app/config/database.php中配置如下： 'redis' => array('cluster' => true,'default' => array('host' => '172.21.107.247','port' => 6379,),'redis1' => array('host' => '172.21.107.248','port' => 6379,),) 其中cl
阅读更多...
Redis的rehash机制

Redis的rehash机制

在Redis中，键值对（Key-Value Pair）存储方式是由字典（Dict）保存的，而字典底层是通过哈希表来实现的。通过哈希表中的节点保存字典中的键值对。我们知道当HashMap中由于Hash冲突（负载因子）超过某个阈值时，出于链表性能的考虑，会进行Resize的操作。Redis也一样。 在redis的具体实现中，使用了一种叫做渐进式哈希(rehashing)的机制来提高字典的缩放效率，避
阅读更多...
如何保证android程序进程不到万不得已的情况下，不会被结束

如何保证android程序进程不到万不得已的情况下，不会被结束

最近，做一个调用系统自带相机的那么一个功能，遇到的坑，在此记录一下。 设备：红米note4 问题起因 因为自定义的相机，很难满足客户的所有需要，比如：自拍杆的支持，优化方面等等。这些方面自定义的相机都不比系统自带的好，因为有些系统都是商家定制的，难免会出现一个奇葩的问题。比如：你在这款手机上运行，无任何问题，然而你换一款手机后，问题就出现了。 比如：小米的红米系列，你启用系统自带拍照功能后
阅读更多...
【吊打面试官系列-Redis面试题】说说 Redis 哈希槽的概念？

【吊打面试官系列-Redis面试题】说说 Redis 哈希槽的概念？

大家好，我是锋哥。今天分享关于 【说说 Redis 哈希槽的概念？】面试题，希望对大家有帮助； 说说 Redis 哈希槽的概念？ Redis 集群没有使用一致性 hash,而是引入了哈希槽的概念，Redis 集群有 16384 个哈希槽，每个 key 通过 CRC16 校验后对 16384 取模来决定放置哪个槽， 集群的每个节点负责一部分 hash 槽。
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2