详解事务模式和Lua脚本,带你吃透Redis 事务
摘要:Redis事务包含两种模式:事务模式和Lua脚本。
本文分享自华为云社区《一文讲透 Redis 事务》,作者: 勇哥java实战分享。
准确的讲,Redis事务包含两种模式:事务模式和Lua脚本。
先说结论:
Redis的事务模式具备如下特点:
- 保证隔离性;
- 无法保证持久性;
- 具备了一定的原子性,但不支持回滚;
- 一致性的概念有分歧,假设在一致性的核心是约束的语意下,Redis 的事务可以保证一致性。
但Lua脚本更具备实用场景,它是另一种形式的事务,他具备一定的原子性,但脚本报错的情况下,事务并不会回滚。Lua脚本可以保证隔离性,而且可以完美的支持后面的步骤依赖前面步骤的结果。
Lua脚本模式的身影几乎无处不在,比如分布式锁、延迟队列、抢红包等场景。
1 事务原理
Redis的事务包含如下命令:
事务包含三个阶段:
- 事务开启,使用 MULTI , 该命令标志着执行该命令的客户端从非事务状态切换至事务状态 ;
- 命令入队,MULTI 开启事务之后,客户端的命令并不会被立即执行,而是放入一个事务队列 ;
- 执行事务或者丢弃。如果收到 EXEC 的命令,事务队列里的命令将会被执行 ,如果是 DISCARD 则事务被丢弃。
下面展示一个事务的例子。
redis> MULTI OK redis> SET msg "hello world" QUEUED redis> GET msg QUEUED redis> EXEC 1) OK 1) hello world
这里有一个疑问?在开启事务的时候,Redis key 可以被修改吗?
在事务执行 EXEC 命令之前 ,Redis key 依然可以被修改。
在事务开启之前,我们可以 watch 命令监听 Redis key 。在事务执行之前,我们修改 key 值 ,事务执行失败,返回 nil 。
通过上面的例子,watch 命令可以实现类似乐观锁的效果 。
2 事务的ACID
2.1 原子性
原子性是指:一个事务中的所有操作,或者全部完成,或者全部不完成,不会结束在中间某个环节。事务在执行过程中发生错误,会被回滚到事务开始前的状态,就像这个事务从来没有执行过一样。
第一个例子:
在执行 EXEC 命令前,客户端发送的操作命令错误,比如:语法错误或者使用了不存在的命令。
redis> MULTI OK redis> SET msg "other msg" QUEUED redis> wrongcommand ### 故意写错误的命令 (error) ERR unknown command 'wrongcommand' redis> EXEC (error) EXECABORT Transaction discarded because of previous errors. redis> GET msg "hello world"
在这个例子中,我们使用了不存在的命令,导致入队失败,整个事务都将无法执行 。
第二个例子:
事务操作入队时,命令和操作的数据类型不匹配 ,入队列正常,但执行 EXEC 命令异常 。
redis> MULTI OK redis> SET msg "other msg" QUEUED redis> SET mystring "I am a string" QUEUED redis> HMSET mystring name "test" QUEUED redis> SET msg "after" QUEUED redis> EXEC 1) OK 2) OK 3) (error) WRONGTYPE Operation against a key holding the wrong kind of value 4) OK redis> GET msg "after"
这个例子里,Redis 在执行 EXEC 命令时,如果出现了错误,Redis 不会终止其它命令的执行,事务也不会因为某个命令执行失败而回滚 。
综上,我对 Redis 事务原子性的理解如下:
- 命令入队时报错, 会放弃事务执行,保证原子性;
- 命令入队时正常,执行 EXEC 命令后报错,不保证原子性;
也就是:Redis 事务在特定条件下,才具备一定的原子性 。
2.2 隔离性
数据库的隔离性是指:数据库允许多个并发事务同时对其数据进行读写和修改的能力,隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。
事务隔离分为不同级别 ,分别是:
- 未提交读(read uncommitted)
- 提交读(read committed)
- 可重复读(repeatable read)
- 串行化(serializable)
首先,需要明确一点:Redis 并没有事务隔离级别的概念。这里我们讨论 Redis 的隔离性是指:并发场景下,事务之间是否可以做到互不干扰。
我们可以将事务执行可以分为 EXEC 命令执行前和 EXEC 命令执行后两个阶段,分开讨论。
- EXEC 命令执行前
在事务原理这一小节,我们发现在事务执行之前 ,Redis key 依然可以被修改。此时,可以使用 WATCH 机制来实现乐观锁的效果。
- EXEC 命令执行后
因为 Redis 是单线程执行操作命令, EXEC 命令执行后,Redis 会保证命令队列中的所有命令执行完 。 这样就可以保证事务的隔离性。
2.3 持久性
数据库的持久性是指 :事务处理结束后,对数据的修改就是永久的,即便系统故障也不会丢失。
Redis 的数据是否持久化取决于 Redis 的持久化配置模式 。
- 没有配置 RDB 或者 AOF ,事务的持久性无法保证;
- 使用了 RDB模式,在一个事务执行后,下一次的 RDB 快照还未执行前,如果发生了实例宕机,事务的持久性同样无法保证;
- 使用了 AOF 模式;AOF 模式的三种配置选项 no 、everysec 都会存在数据丢失的情况 。always 可以保证事务的持久性,但因为性能太差,在生产环境一般不推荐使用。
综上,redis 事务的持久性是无法保证的 。
2.4 一致性
一致性的概念一直很让人困惑,在我搜寻的资料里,有两类不同的定义。
- 维基百科
我们先看下维基百科上一致性的定义:
Consistency ensures that a transaction can only bring the database from one valid state to another, maintaining database invariants: any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination thereof. This prevents database corruption by an illegal transaction, but does not guarantee that a transaction is correct. Referential integrity guarantees the primary key – foreign key relationship.
在这段文字里,一致性的核心是“约束”,“any data written to the database must be valid according to all defined rules ”。
如何理解约束?这里引用知乎问题 如何理解数据库的内部一致性和外部一致性,蚂蚁金服 OceanBase 研发专家韩富晟回答的一段话:
“约束”由数据库的使用者告诉数据库,使用者要求数据一定符合这样或者那样的约束。当数据发生修改时,数据库会检查数据是否还符合约束条件,如果约束条件不再被满足,那么修改操作不会发生。
关系数据库最常见的两类约束是“唯一性约束”和“完整性约束”,表格中定义的主键和唯一键都保证了指定的数据项绝不会出现重复,表格之间定义的参照完整性也保证了同一个属性在不同表格中的一致性。
“ Consistency in ACID ”是如此的好用,以至于已经融化在大部分使用者的血液里了,使用者会在表格设计的时候自觉的加上需要的约束条件,数据库也会严格的执行这个约束条件。
所以事务的一致性和预先定义的约束有关,保证了约束即保证了一致性。
我们细细品一品这句话: This prevents database corruption by an illegal transaction, but does not guarantee that a transaction is correct。
写到这里可能大家还是有点模糊,我们举经典转账的案例。
我们开启一个事务,张三和李四账号上的初始余额都是1000元,并且余额字段没有任何约束。张三给李四转账1200元。张三的余额更新为 -200 , 李四的余额更新为2200。
从应用层面来看,这个事务明显不合法,因为现实场景中,用户余额不可能小于 0 , 但是它完全遵循数据库的约束,所以从数据库层面来看,这个事务依然保证了一致性。
Redis 的事务一致性是指:Redis 事务在执行过程中符合数据库的约束,没有包含非法或者无效的错误数据。
我们分三种异常场景分别讨论:
- 执行 EXEC 命令前,客户端发送的操作命令错误,事务终止,数据保持一致性;
- 执行 EXEC 命令后,命令和操作的数据类型不匹配,错误的命令会报错,但事务不会因为错误的命令而终止,而是会继续执行。正确的命令正常执行,错误的命令报错,从这个角度来看,数据也可以保持一致性;
- 执行事务的过程中,Redis 服务宕机。这里需要考虑服务配置的持久化模式。
- 无持久化的内存模式:服务重启之后,数据库没有保持数据,因此数据都是保持一致性的;
- RDB / AOF 模式: 服务重启后,Redis 通过 RDB / AOF 文件恢复数据,数据库会还原到一致的状态。
综上所述,在一致性的核心是约束的语意下,Redis 的事务可以保证一致性。
- 《设计数据密集型应用》
这本书是分布式系统入门的神书。在事务这一章节有一段关于 ACID 的解释:
Atomicity, isolation, and durability are properties of the database,whereas consistency (in the ACID sense) is a property of the application. The application may rely on the database’s atomicity and isolation properties in order to achieve consistency, but it’s not up to the database alone. Thus, the letter C doesn’t really belong in ACID.
原子性,隔离性和持久性是数据库的属性,而一致性(在 ACID 意义上)是应用程序的属性。应用可能依赖数据库的原子性和隔离属性来实现一致性,但这并不仅取决于数据库。因此,字母 C 不属于 ACID 。
很多时候,我们一直在纠结的一致性,其实就是指符合现实世界的一致性,现实世界的一致性才是事务追求的最终目标。
为了实现现实世界的一致性,需要满足如下几点:
- 保证原子性,持久性和隔离性,如果这些特征都无法保证,那么事务的一致性也无法保证;
- 数据库本身的约束,比如字符串长度不能超过列的限制或者唯一性约束;
- 业务层面同样需要进行保障 。
2.5 事务特点
我们通常称 Redis 为内存数据库 , 不同于传统的关系数据库,为了提供了更高的性能,更快的写入速度,在设计和实现层面做了一些平衡,并不能完全支持事务的 ACID。
Redis 的事务具备如下特点:
- 保证隔离性;
- 无法保证持久性;
- 具备了一定的原子性,但不支持回滚;
- 一致性的概念有分歧,假设在一致性的核心是约束的语意下,Redis 的事务可以保证一致性。
从工程角度来看,假设事务操作中每个步骤需要依赖上一个步骤返回的结果,则需要通过 watch 来实现乐观锁 。
3 Lua 脚本
3.1 简介
Lua 由标准 C 编写而成,代码简洁优美,几乎在所有操作系统和平台上都可以编译,运行。Lua 脚本可以很容易的被 C/C ++ 代码调用,也可以反过来调用 C/C++ 的函数,这使得 Lua 在应用程序中可以被广泛应用。
Lua 脚本在游戏领域大放异彩,大家耳熟能详的《大话西游II》,《魔兽世界》都大量使用 Lua 脚本。Java 后端工程师接触过的 api 网关,比如 Openresty ,Kong 都可以看到 Lua 脚本的身影。
从 Redis 2.6.0 版本开始, Redis内置的 Lua 解释器,可以实现在 Redis 中运行 Lua 脚本。
使用 Lua 脚本的好处 :
- 减少网络开销。将多个请求通过脚本的形式一次发送,减少网络时延。
- 原子操作。Redis会将整个脚本作为一个整体执行,中间不会被其他命令插入。
- 复用。客户端发送的脚本会永久存在 Redis 中,其他客户端可以复用这一脚本而不需要使用代码完成相同的逻辑。
Redis Lua 脚本常用命令:
3.2 EVAL 命令
命令格式:
EVAL script numkeys key [key ...] arg [arg ...]
说明:
- script是第一个参数,为 Lua 5.1脚本;
- 第二个参数numkeys指定后续参数有几个 key;
- key [key ...],是要操作的键,可以指定多个,在 Lua 脚本中通过KEYS[1], KEYS[2]获取;
- arg [arg ...],参数,在 Lua 脚本中通过ARGV[1], ARGV[2]获取。
简单实例:
redis> eval "return ARGV[1]" 0 100 "100" redis> eval "return {ARGV[1],ARGV[2]}" 0 100 101 1) "100" 2) "101" redis> eval "return {KEYS[1],KEYS[2],ARGV[1]}" 2 key1 key2 first second 1) "key1" 2) "key2" 3) "first" 4) "second"
下面演示下 Lua 如何调用 Redis 命令 ,通过redis.call()来执行了 Redis 命令 。
redis> set mystring 'hello world' OK redis> get mystring "hello world" redis> EVAL "return redis.call('GET',KEYS[1])" 1 mystring "hello world" redis> EVAL "return redis.call('GET','mystring')" 0
"hello world"
3.3 EVALSHA 命令
使用 EVAL 命令每次请求都需要传输 Lua 脚本 ,若 Lua 脚本过长,不仅会消耗网络带宽,而且也会对 Redis 的性能造成一定的影响。
思路是先将 Lua 脚本先缓存起来 , 返回给客户端 Lua 脚本的 sha1 摘要。 客户端存储脚本的 sha1 摘要 ,每次请求执行 EVALSHA 命令即可。
EVALSHA 命令基本语法如下:
redis> EVALSHA sha1 numkeys key [key ...] arg [arg ...]
实例如下:
redis> SCRIPT LOAD "return 'hello world'" "5332031c6b470dc5a0dd9b4bf2030dea6d65de91" redis> EVALSHA 5332031c6b470dc5a0dd9b4bf2030dea6d65de91 0 "hello world"
4 事务 VS Lua 脚本
从定义上来说, Redis 中的脚本本身就是一种事务, 所以任何在事务里可以完成的事, 在脚本里面也能完成。 并且一般来说, 使用脚本要来得更简单,并且速度更快。
因为脚本功能是 Redis 2.6 才引入的, 而事务功能则更早之前就存在了, 所以 Redis 才会同时存在两种处理事务的方法。
不过我们并不打算在短时间内就移除事务功能, 因为事务提供了一种即使不使用脚本, 也可以避免竞争条件的方法, 而且事务本身的实现并不复杂。
-- https://redis.io/
Lua 脚本是另一种形式的事务,他具备一定的原子性,但脚本报错的情况下,事务并不会回滚。Lua 脚本可以保证隔离性,而且可以完美的支持后面的步骤依赖前面步骤的结果。
Lua 脚本模式的身影几乎无处不在,比如分布式锁、延迟队列、抢红包等场景。
不过在编写 Lua 脚本时,要注意如下两点:
- 为了避免 Redis 阻塞,Lua 脚本业务逻辑不能过于复杂和耗时;
- 仔细检查和测试 Lua 脚本 ,因为执行 Lua 脚本具备一定的原子性,不支持回滚。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
解Bug之路-应用999线升高
前言 监控指标诚然是发现问题于微末之时的极佳手段,但指标往往有其表达的极限。在很多情况下,单独看一个黄金指标并不能表征系统的健康程度,反而有可能被其迷惑,进而忽略相关问题。(本文所提及的Linux Kernel源码版本为4.18.10) Bug现场 某天中午,某应用的999线突然升高。由于是个QPS高达几十万的查询服务,1分钟的升高就会影响数千个请求。初步判断应用容量不够,直接进行相关扩容,扩容后反而加剧了问题!不得已又做了一次紧急扩容,999线才恢复。这两波操作过去,20多分钟已经过去了。 为了防止问题再次发生,我们必须要彻查相关原因。于是笔者也就参与了调查。 Young GC升高 首先是去看常用的指标,例如CPU idle, GC Time。发现有一些机器的CPU达到了60%,而在这些机器中,young gc有一个大幅度的增长。 为什么Young GC升高 看上去GC问题。那么,笔者就开始思考为什么young gc升高。翻看gc日志。看到故障期间,不停的young gc。但这些young gc的表现很诡异。有时候young gc很快,只有数十毫秒,有时确达到了数百毫秒。而且...
- 下一篇
那些让 ChatGPT review 代码的程序员,后来都怎么样了?
Review PR 是开源项目的重要一环。对于项目维护者来说,社区有人来贡献代码,是一件值得开心的事情,说明自己的项目受到了认可。开源项目将通过社区贡献变得更强大。对于贡献代码的开发者来说,编程能力获得了开源项目的认可,也是一件值得写到简历的事情。在 Review 代码的过程中加上了 ChatGPT,会发生什么化学反应? 我司 Second State 最近在自己的开源项目的 GitHub repo 中引入了一个基于 ChatGPT 的 PR Review 机器人。当有人提交新的 PR 的时候,这个机器人会总结 PR在干什么、潜在的风险与问题、以及这个 PR 里的每次 commit 都干了什么。这对 Reviewer 来说,能够大大增加 review PR 的速度。更重要的是 ChatGPT 还能找到代码里的潜在问题,提供更高效的写代码的方式。下面我们来看一个真实的例子。 看看下面这段代码,你有发现什么问题吗? let limit = (n as f64).sqrt() as i32; for a in 2..limit { if n % a == 0 { return JsVa...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS8编译安装MySQL8.0.19
- CentOS关闭SELinux安全模块
- CentOS8安装Docker,最新的服务器搭配容器使用
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7设置SWAP分区,小内存服务器的救世主
- Docker安装Oracle12C,快速搭建Oracle学习环境