通常我们提及数据库都不可避免的要提到事务,那么什么是事务呢?事务是指作为单个逻辑工作单元执行的一系列操作。所以,首先事务是一系列操作,这一系列操作具有二态性,即完全地执行或者完全地不执行。因此事务处理可以确保除非事务单元内的所有操作的成功完成,否则不会想数据库更新面向数据的资源。我们这里举一个例子,数据库中除查询操作以外,插入(Insert)、删除(Delete)和更新(Update)这三种操作都会对数据造成影响,因为事务处理能够保证一系列操作可以完全地执行或者完全不执行,因此在一个事务被提交以后,该事务中的任何一条SQL语句在被执行的时候,都会生成一条撤销日志(Undo Log),而撤销日志中记录的是和当前擦作完全相反的操作,比如删除的相反操作是插入,插入的相反操作是删除等。我们通常所说的事务回滚其实就是去执行这些插销日志里的相反操作,这同样告诉我们一个道理,只有事务中的一系列操作完全执行的情况下可以回滚,如果是在意外情况下导致事务中的一系列操作没有完全执行,这个时候我们是不能保证数据一定可以回滚的。
创新互联建站服务项目包括乐山网站建设、乐山网站制作、乐山网页制作以及乐山网络营销策划等。多年来,我们专注于互联网行业,利用自身积累的技术优势、行业经验、深度合作伙伴关系等,向广大中小型企业、政府机构等提供互联网行业的解决方案,乐山网站推广取得了明显的社会效益与经济效益。目前,我们服务的客户以成都为中心已经辐射到乐山省份的部分城市,未来相信会继续扩大服务区域并继续获得客户的支持与信任!
在数据库相关理论中,一个逻辑工作单元想要成为事务,就必须满足 ACID,即原子性、一致性、隔离性和持久性。
我们对数据库中事务处理的相关理论有了一个基本的认识,或许这个世界上的数据库系统千差万别,但我相信在事务处理这个问题上它们最终会殊途同归,就像我们解决并发过程中的冲突问题,常规的做法依然是加锁一样,这是我之所以要花费精力去理解和解释这些理论知识的原因,技术可谓是日新月异,如果我们总是一味地为新技术而疲于奔命,那么或许我们会渐渐地失去对这个行业的热爱,我相信原理永远比框架更为重要。
redis事务提供了一种“将多个命令打包, 然后一次性、按顺序地执行”的机制, 并且事务在执行的期间不会主动中断 —— 服务器在执行完事务中的所有命令之后, 才会继续处理其他客户端的其他命令。
Redis中的事务是可以视为一个队列,即我们可以通过MULTI开始一个事务,这相当于我们声明了一个命令队列。接下来,我们向Redis中提交的每条命令,都会被排入这个命令队列。当我们输入EXEC命令时,将触发当前事务,这相当于我们从命令队列中取出命令并执行,所以Redis中一个事务从开始到执行会经历 开始事务 、 命令入队 和 执行事务 三个阶段。下面是一个在Redis中使用事务的简单示例:
127
.0
.0
.1
:6379>
MULTI
OK
127
.0
.0
.1
:6379>
SET
Book_Name "
GIt
Pro"
QUEUED
127
.0
.0
.1
:6379>
SADD
Program_Language "
C++" "
C#" "
Jave" "
Python"
QUEUED
127
.0
.0
.1
:6379>
GET
Book_Name
QUEUED
127
.0
.0
.1
:6379>
EXEC
1)
OK
2) (
integer) 4
3) "
GIt
Pro"
我们可以注意到Redis中的事务和通常意义上的事务基本上是一致的,即
一个事务从开始到执行会经历以下三个阶段:
下面将分别介绍事务的这三个阶段。
1)开始事务
MULTI命令的执行标记着事务的开始:
redis>
MULTI
OK
这个命令唯一做的就是, 将客户端的 REDIS_MULTI 选项打开, 让客户端从非事务状态切换到事务状态。
图1 客户端状态转换
2)命令入队
当客户端处于非事务状态下时, 所有发送给服务器端的命令都会立即被服务器执行:
redis>
SET msg
"hello moto"
OK
redis> GET msg
"hello moto"
但是, 当客户端进入事务状态之后, 服务器在收到来自客户端的命令时, 不会立即执行命令, 而是将这些命令全部放进一个事务队列里, 然后返回QUEUED, 表示命令已入队:
redis>
MULTI
OK
redis> SET msg
"hello moto"
QUEUED
redis> GET msg
QUEUED
其原理如图2所示
图2. 命令入队
3)执行事务
前面说到, 当客户端进入事务状态之后, 客户端发送的命令就会被放进事务队列里。
但其实并不是所有的命令都会被放进事务队列, 其中的例外就是 EXEC 、 DISCARD 、 MULTI 和 WATCH 这四个命令 —— 当这四个命令从客户端发送到服务器时, 它们会像客户端处于非事务状态一样, 直接被服务器执行:
图3 执行事务
如果客户端正处于事务状态, 那么当EXEC命令执行时, 服务器根据客户端所保存的事务队列, 以先进先出(FIFO)的方式执行事务队列中的命令: 最先入队的命令最先执行, 而最后入队的命令最后执行。
执行事务中的命令所得的结果会以 FIFO 的顺序保存到一个回复队列中。
当事务队列里的所有命令被执行完之后,EXEC命令会将回复队列作为自己的执行结果返回给客户端, 客户端从事务状态返回到非事务状态, 至此, 事务执行完毕。
redis事务使用了multi、exec、discard、watch、unwatch命令,命令的作用如图4所示:
图4 事务命令
使用案例:
图5. 正常执行
图6 放弃事务
图7 命令错误
图8 语法错误
使用watch检测balance,事务期间balance数据未变动,事务执行成功
图9 watch用法1
WATCH命令用于在事务开始之前监视任意数量的键: 当调用EXEC命令执行事务时, 如果任意一个被监视的键已经被其他客户端修改了, 那么整个事务不再执行, 直接返回失败。
图10 watch用法2
图11 修改balance
在每个代表数据库的 redis.h/redisDb 结构类型中, 都保存了一个 watched_keys 字典, 字典的键是这个数据库被监视的键, 而字典的值则是一个链表, 链表中保存了所有监视这个键的客户端。
比如说,以下字典就展示了一个 watched_keys 字典的例子:
图11 watch实现的原理
其中, 键 key1 正在被 client2 、 client5 和 client1 三个客户端监视, 其他一些键也分别被其他别的客户端监视着。
WATCH 命令的作用, 就是将当前客户端和要监视的键在 watched_keys 中进行关联。
举个例子, 如果当前客户端为 client10086 , 那么当客户端执行 WATCH key1 key2 时, 前面展示的 watched_keys 将被修改成这个样子:
图12 watch实现原理2
通过watched_keys字典, 如果程序想检查某个键是否被监视, 那么它只要检查字典中是否存在这个键即可; 如果程序要获取监视某个键的所有客户端, 那么只要取出键的值(一个链表), 然后对链表进行遍历即可。
图13 watch的触发
当客户端发送 EXEC 命令、触发事务执行时, 服务器会对客户端的状态进行检查:
在Redis中,事务总是具有原子性(Atomicity)、一致性(Consistency)和隔离性(Isolation),并且当Redis运行在某种特定的持久化模式下,事务也具有持久性性(Durability)。
事务具有原子性指的是, 数据库将事务中的多个操作当作一个整体来执行,服务器要么就执行事务中的所有操作, 要么就一个操作也不执行。对于Redis的事务功能来说,事务队列中的命令要么就全部都执行,要么就一个都不执行,因此, Redis的事务是具有原子性的。
Redis的事务和传统的关系型数据库事务的最大区别在于, Redis不支持事务回滚机制(rollback), 即使事务队列中的某个命令在执行期间出现了错误,整个事务也会继续执行下去,直到将事务队列中的所有命令都执行完毕为止。 下面展示了即使RPUSH命令在执行期间出现了错误,事务的后续命令也会继续执行下去, 并且之前执行的命令也不会有任何影响:
127
.0
.0
.1
:6379>
set
msg
hello
OK
127
.0
.0
.1
:6379>
multi
OK
127
.0
.0
.1
:6379>
sadd
fruit
apple
banana
cherry
QUEUED
127
.0
.0
.1
:6379>
rpush
msg
bye
redis
QUEUED
127
.0
.0
.1
:6379>
sadd
alphabet
a
b
c
QUEUED
127
.0
.0
.1
:6379>
exec
1) (
integer) 3
2) (
error)
WRONGTYPE
Operation
against
a
key
holding
the
wrong
kind
of
value
3) (
integer) 3
不支持事务回滚是因为这种复杂的功能和Redis追求简单高效的设计主旨不相符,并且Redis事务的执行时错误通常都是编程错误产生的, 这种错误通常只会出现在开发环境中, 而很少会在实际的生产环境中出现。
事务的一致性是指,如果数据库执行前是一致的,那么在事务执行后,无论事务是否执行成功,数据库也应该是一致的。
事务的耐久性指的是,当一个事务执行完毕时,执行这个事务所得的结果巳经被保存到 永久性存储介质(比如硬盘)里面了, 即使服务器在事务执行完毕 之后停机, 执行事务所得的结果也不会丢失。Redis事务的耐久性由服务器所使用持久化模式决定的:(1) 当服务器在无持久化的内存模式下运作时,事务不具有耐久性。因为一旦服务器停机,服务器所有的数据都将丢失。(2) 当服务器在ROB持久化模式下运作时,事务同样不具有耐久性。因为服务器只会在特定的保存条件下才会执行BGSAVE命令,并且异步执行的BGSAVE命令不能保证事务的数据第一时间被保存到硬盘上。(3) 当服务器运行在AOF持久化模式下,并且appendfsync选项的值为always时,程序总会在执行命令之后调用同步(sync)函数,将命令数据真正地保存到硬盘里。
文章题目:Python:深入理解Redis事务
本文URL:https://www.cdcxhl.com/article44/ggjpee.html
成都网站建设公司_创新互联,为您提供微信小程序、手机网站建设、网站维护、Google、网页设计公司、外贸建站
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联