4 种策略让 MySQL 和 Redis 数据保持一致

ops/2024/9/24 13:18:05/

先阐明一下 MySQL 和 Redis 的关系:MySQL 是数据库,用来持久化数据,一定程度上保证数据的可靠性;Redis 是用来当缓存,用来提升数据访问的性能。

关于如何保证 MySQL 和 Redis 中的数据一致(即缓存一致性问题),这是一个非常经典的问题。

使用过缓存的人都应该知道,在实际应用场景中,要想实时刻保证缓存和数据库中的数据一样,很难做到。

基本上都是尽可能让他们的数据在绝大部分时间内保持一致,并保证最终是一致的。

1、缓存不一致是如何产生的

如果数据一直没有变更,那么就不会出现缓存不一致的问题。

通常缓存不一致是发生在数据有变更的时候。因为每次数据变更你需要同时操作数据库和缓存,而他们又属于不同的系统,无法做到同时操作成功或失败,总会有一个时间差。在并发读写的时候可能就会出现缓存不一致的问题(理论上通过分布式事务可以保证这一点,不过实际上基本上很少有人这么做)。

虽然没办法在数据有变更时,保证缓存和数据库强一致,但对缓存的更新还是有一定设计方法的,遵循这些设计方法,能够让这个不一致的影响时间和影响范围最小化。

2、缓存更新的几种设计

缓存更新的设计方法大概有以下四种:

先删除缓存,再更新数据库(这种方法在并发下最容易出现长时间的脏数据,不可取)

先更新数据库,删除缓存(Cache Aside Pattern)

只更新缓存,由缓存自己同步更新数据库(Read/Write Through Pattern)

只更新缓存,由缓存自己异步更新数据库(Write Behind Cache Pattern)

接下来详细介绍一些这四种设计方法

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

这种方法在并发读写的情况下容易出现缓存不一致的问题

在这里插入图片描述
如上图所示,其可能的执行流程顺序为:

客户端1 触发更新数据A的逻辑

客户端2 触发查询数据A的逻辑

客户端1 删除缓存中数据A

客户端2 查询缓存中数据A,未命中

客户端2 从数据库查询数据A,并更新到缓存中

客户端1 更新数据库中数据A

可见,最后缓存中的数据 A 跟数据库中的数据 A 是不一致的,缓存中的数据A是旧的脏数据。

因此一般不建议使用这种方式。

2.2 先更新数据库,再让缓存失效
在这里插入图片描述

这种方法在并发读写的情况下,也可能会出现短暂缓存不一致的问题

如上图所示,其可能执行的流程顺序为:

客户端1 触发更新数据A的逻辑

客户端2 触发查询数据A的逻辑

客户端3 触发查询数据A的逻辑

客户端1 更新数据库中数据A

客户端2 查询缓存中数据A,命中返回(旧数据)

客户端1 让缓存中数据A失效

客户端3 查询缓存中数据A,未命中

客户端3 查询数据库中数据A,并更新到缓存中

可见,最后缓存中的数据A和数据库中的数据 A 是一致的,理论上可能会出现一小段时间数据不一致,不过这种概率也比较低,大部分的业务也不会有太大的问题。

2.3 只更新缓存,由缓存自己同步更新数据库(Read/Write Through Pattern)

这种方法相当于是业务只更新缓存,再由缓存去同步更新数据库。一个Write Through的 例子如下:

在这里插入图片描述

如上图所示,其可能执行的流程顺序为:

客户端1 触发更新数据 A 的逻辑

客户端2 触发查询数据 A 的逻辑

客户端1 更新缓存中数据 A,缓存同步更新数据库中数据 A,再返回结果

客户端2 查询缓存中数据 A,命中返回

Read Through 和 WriteThrough 的流程类似,只是在客户端查询数据A时,如果缓存中数据A失效了(过期或被驱逐淘汰),则缓存会同步去数据库中查询数据A,并缓存起来,再返回给客户端。

这种方式缓存不一致的概率极低,只不过需要对缓存进行专门的改造。

2.4 只更新缓存,由缓存自己异步更新数据库(Write Behind Cache Pattern)

这种方式性详单于是业务只操作更新缓存,再由缓存异步去更新数据库,例如:
在这里插入图片描述

如上图所示,其可能的执行流程顺序为:

客户端1 触发更新数据 A 的逻辑

客户端2 触发查询数据 A 的逻辑

客户端1 更新缓存中的数据 A,返回

客户端2 查询缓存中的数据 A,命中返回

缓存异步更新数据 A 到数据库

这种方式的优势是读写的性能都非常好,基本上只要操作完内存后就返回给客户端了,但是其是非强一致性,存在丢失数据的情况。

如果在缓存异步将数据更新到数据库中时,缓存服务挂了,此时未更新到数据库中的数据就丢失了。

总结

上面讲到的几种缓存更新的设计方式,都是前人总结出来的经验,这些方式或多或少都有一些弊端,并不完美,实际上也很难有完美的设计。大家在做系统设计的时候,也不要去追求完美,要有一些取舍,找到一种最适合自己业务场景的方式就行。


http://www.ppmy.cn/ops/4776.html

相关文章

AVB简介(二): gPTP简介

AVB简介(二): gPTP简介 一、时间同步要解决的问题二、gPTP的主要思想2.1 体系结构2.2 主时钟选取2.3 绝对时间同步2.4 相对时间同步 三、影响校时精度的因素3.1 传输时延不对称3.2 驻留时间3.3 时间戳采样点3.4 时钟频率3.5 传输路径延时测量方式3.6 时钟…

Mac 安装comfigUI (M1)

注:系统要升到最新的 (Xcode 13.3.1 or later) Requirements Mac computers with Apple silicon or AMD GPUsmacOS 12.3 or laterPython 3.7 or laterXcode command-line tools: xcode-select --install 安装 pytorch 查看这个内容安装 h…

ipv4Bypass:一款基于IPv6实现的IPv4安全绕过与渗透测试工具

关于ipv4Bypass ipv4Bypass是一款基于IPv6实现的安全绕过与渗透测试工具,该工具专为红队研究人员设计,可以帮助广大研究人员通过IPv6绕过目标安全策略,以此来检测安全检测机制的健壮性。 20世纪90年代是互联网爆炸性发展时期,随着…

Spring AI ETL 流水线

先纠正 Spring AI 使用本地 Ollama Embeddings 中的一个错误,当启动 Ollama 之后,Windows会有托盘图标,此时已经启动了 Ollama 的服务,访问 Embedding 时不需要运行 ollama run gemma ,只有访问 chat 时才需要启动一个…

Webpack打包

Webpack是 JS 静态打包神器,通过内部组件进行一系列操作,对前端代码进行替换、转义、JS浏览器兼容性等处理,最终生成前端应用所需文件包括 Html、JS和 CSS。Webpack主要以下几部分组成,这些配置都可以定义在webpack.config.js&…

Flink SQL

文章目录 一、Flink SQL1、sql-client准备1.1 基于yarn-session模式1.2 常用配置 2、流处理中的表2.1 动态表和持续查询2.2 将流转换成动态表2.3 用SQL持续查询2.4 将动态表转换为流 3、时间属性3.1 事件时间3.2 处理时间 4、DDL(Data Definition Language&#xff…

「51媒体」展会媒体邀约资源,媒体宣传服务执行

传媒如春雨,润物细无声,大家好,我是51媒体网胡老师。 在组织展会时,媒体宣传服务的执行是提升展会知名度和影响力的关键环节。 确定目标媒体:根据展会的主题和目标受众,选择适合的媒体进行邀请。这可能包括…

mac 使用nvm配置nodejs

您可以按照以下步骤在Mac上安装指定版本的Node.js: 首先,请确保您已经安装了Homebrew。如果没有,请在终端中运行以下命令来安装Homebrew: /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install…