事务是数据库的一个重要属性,有关事务的4个特性,原子性、一致性、隔离性、持久性,也就是ACID,这些属性既包含了对事务执行结果的要求,也有数据库在事务执行前后的数据状态变化的要求。

Redis可以完全保证ACID属性吗?如果保证不了,在一些场景下数据可能会出错,所以我们需要了解redis对于这些特性的支持情况

事务ACID的要求

原子性

指事务是一个不可分割的工作单位,事务中的操作要么都发生,要么都不发生。

一致性

事务前后数据的完整性必须保持一致。

例如

A有800,B有200,A给B转账200

操作前A:800,B:200

操作后A:600,B:400

数据库只有操作前后这两种状态,没有其他中间状态的存在

隔离性

事务的隔离性是多个用户并发访问数据库时,数据库为每一个用户开启的事务,不能被其他事务的操作数据所干扰,多个并发事务之间要相互隔离。这个会牵扯到数据库的隔离级别,在这边不做详细的介绍,后面会单独出一篇文章介绍

持久性

持久性是指一个事务一旦被提交,它对数据库中数据的改变就是永久性的,接下来即使数据库发生故障也不应该对其有任何影响

Redis的事务实现

事务的执行包含三个步骤,Redis提供了MULTI、EXEC两个命令完成这三个步骤

第一步,客户端要使用一个命令显式地表示一个事务的开启。在 Redis 中,这个命令就是 MULTI。

第二步,客户端把事务中本身要执行的具体操作(例如增删改数据)发送给服务器端。这些操作就是 Redis 本身提供的数据读写命令,例如 GET、SET 等。不过,这些命令虽然被客户端发送到了服务器端,但 Redis 实例只是把这些命令暂存到一个命令队列中,并不会立即执行。

第三步,客户端向服务器端发送提交事务的命令,让数据库实际执行第二步中发送的具体操作。Redis 提供的 EXEX命令就是事务提交的命令。当服务端收到这个命令后,才会实际执行命令队列中的所有命令

下面代码显示了使用命令执行事务的一个过程

#开启事务
127.0.0.1:6379> MULTI
OK
#将a:stock减1,
127.0.0.1:6379> DECR a:stock
QUEUED
#将b:stock减1
127.0.0.1:6379> DECR b:stock
QUEUED
#实际执行事务
127.0.0.1:6379> EXEC
1) (integer) 4
2) (integer) 9

我们假设 a:stock、b:stock 两个键的初始值是 5 和 10。在 MULTI 命令后执行的两个 DECR 命令,是把 a:stock、b:stock 两个键的值分别减 1,它们执行后的返回结果都是 QUEUED,这就表示,这些操作都被暂存到了命令队列,还没有实际执行。等到执行了 EXEC 命令后,可以看到返回了 4、9,这就表明,两个 DECR 命令已经成功地执行了。

好了,通过使用 MULTI 和 EXEC 命令,我们可以实现多个操作的共同执行,但是这符合事务要求的 ACID 属性吗?接下来,我们就来具体分析下。

Redis 的事务机制能保证哪些属性

原子性

主要正对三种异常情况看下

第一种

在执行EXEC命令前,客户端发送操作命令本身存在错误(比如语法错误,使用了不存在的命令),在命令入队时就被 Redis 实例判断出来了。

对于这种情况,在命令入队时,Redis 就会报错并且记录下这个错误。此时,我们还能继续提交命令操作。等到执行了 EXEC 命令之后,Redis 就会拒绝执行所有提交的命令操作,返回事务失败的结果。这样一来,事务中的所有命令都不会再被执行了,保证了原子性。

#开启事务
127.0.0.1:6379> MULTI
OK
#发送事务中的第一个操作,但是Redis不支持该命令,返回报错信息
127.0.0.1:6379> PUT a:stock 5
(error) ERR unknown command `PUT`, with args beginning with: `a:stock`, `5`,
#发送事务中的第二个操作,这个操作是正确的命令,Redis把该命令入队
127.0.0.1:6379> DECR b:stock
QUEUED
#实际执行事务,但是之前命令有错误,所以Redis拒绝执行
127.0.0.1:6379> EXEC
(error) EXECABORT Transaction discarded because of previous errors.

在这个例子中,事务里包含了一个 Redis 本身就不支持的 PUT 命令,所以,在 PUT 命令入队时,Redis 就报错了。虽然,事务里还有一个正确的 DECR 命令,但是,在最后执行 EXEC 命令后,整个事务被放弃执行了。

第二种

事务在操作入队是,命令和操作的数据类型不匹配。但是,在执行完 EXEC 命令以后,Redis 实际执行这些事务操作时,就会报错。不过,需要注意的是,虽然 Redis 会对错误命令报错,但还是会把正确的命令执行完。在这种情况下,事务的原子性就无法得到保证了。

#开启事务
127.0.0.1:6379> MULTI
OK
#发送事务中的第一个操作,LPOP命令操作的数据类型不匹配,此时并不报错
127.0.0.1:6379> LPOP a:stock
QUEUED
#发送事务中的第二个操作
127.0.0.1:6379> DECR b:stock
QUEUED
#实际执行事务,事务第一个操作执行报错
127.0.0.1:6379> EXEC
1) (error) WRONGTYPE Operation against a key holding the wrong kind of value
2) (integer) 8

看到这里,你可能有个疑问,传统数据库(例如 MySQL)在执行事务时,会提供回滚机制,当事务执行发生错误时,事务中的所有操作都会撤销,已经修改的数据也会被恢复到事务执行前的状态,那么,在刚才的例子中,如果命令实际执行时报错了,是不是可以用回滚机制恢复原来的数据呢?

其实,Redis 中并没有提供回滚机制。虽然 Redis 提供了 DISCARD 命令,但是,这个命令只能用来主动放弃事务执行,把暂存的命令队列清空,起不到回滚的效果。

#读取a:stock的值4
127.0.0.1:6379> GET a:stock
"4"
#开启事务
127.0.0.1:6379> MULTI
OK
#发送事务的第一个操作,对a:stock减1
127.0.0.1:6379> DECR a:stock
QUEUED
#执行DISCARD命令,主动放弃事务
127.0.0.1:6379> DISCARD
OK
#再次读取a:stock的值,值没有被修改
127.0.0.1:6379> GET a:stock
"4"

第三种

在执行事务的EXEC命令时,Redis实例发生故障,导致事务执行失败

在这种情况下,如果 Redis 开启了 AOF 日志,那么,只会有部分的事务操作被记录到 AOF 日志中。我们需要使用 redis-check-aof 工具检查 AOF 日志文件,这个工具可以把未完成的事务操作从 AOF 文件中去除。这样一来,我们使用 AOF 恢复实例后,事务操作不会再被执行,从而保证了原子性。

当然,如果 AOF 日志并没有开启,那么实例重启后,数据也都没法恢复了,此时,也就谈不上原子性了。

做个小总结

  • 命令入队时报错,会放弃事务执行,保证原子性
  • 命令入队时正常,执行是报错,不保证原则性
  • EXEC命令时,实例发生故障,如果开启了AOF日志,可以保证原子性

一致性

和原子性一样也要分三种情况考虑

第一种

命令入队就报错

事务会放弃执行,保证一致性

第二种

命令入队正常,实际执行报错

在这种情况下,有错误的命令不会被执行,正确的命令可以正常执行,也不会改变数据库的一致性。

第三种

EXEC命令执行时实例发生故障

在这种情况下,实例故障后会进行重启,这就和数据恢复的方式有关了,我们要根据实例是否开启了 RDB 或 AOF 来分情况讨论下。

如果我们没有开启 RDB 或 AOF,那么,实例故障重启后,数据都没有了,数据库是一致的。

如果我们使用了 RDB 快照,因为 RDB 快照不会在事务执行时执行,所以,事务命令操作的结果不会被保存到 RDB 快照中,使用 RDB 快照进行恢复时,数据库里的数据也是一致的。

如果我们使用了 AOF 日志,而事务操作还没有被记录到 AOF 日志时,实例就发生了故障,那么,使用 AOF 日志恢复的数据库数据是一致的。如果只有部分操作被记录到了 AOF 日志,我们可以使用 redis-check-aof 清除事务中已经完成的操作,数据库恢复后也是一致的。

所以,总结来说,在命令执行错误或 Redis 发生故障的情况下,Redis 事务机制对一致性属性是有保证的。接下来,我们再继续分析下隔离性。

隔离性

事务的隔离性保证,会受到和事务一起执行的并发操作的影响。而事务执行又可以分成命令入队(EXEC 命令执行前)和命令实际执行(EXEC 命令执行后)两个阶段,所以,我们就针对这两个阶段,分成两种情况来分析:

1、并发操作在 EXEC 命令前执行,此时,隔离性的保证要使用 WATCH 机制来实现,否则隔离性无法保证;

2、并发操作在 EXEC 命令后执行,此时,隔离性可以保证。

我们先来看第一种情况。一个事务的 EXEC 命令还没有执行时,事务的命令操作是暂存在命令队列中的。此时,如果有其它的并发操作,我们就需要看事务是否使用了 WATCH 机制。

WATCH 机制的作用是,在事务执行前,监控一个或多个键的值变化情况,当事务调用 EXEC 命令执行时,WATCH 机制会先检查监控的键是否被其它客户端修改了。如果修改了,就放弃事务执行,避免事务的隔离性被破坏。然后,客户端可以再次执行事务,此时,如果没有并发修改事务数据的操作了,事务就能正常执行,隔离性也得到了保证。

WATCH 机制的具体实现是由 WATCH 命令实现的,我给你举个例子,你可以看下下面的图,进一步理解下 WATCH 命令的使用。

在 t2 时刻,客户端 X 发送的 EXEC 命令还没有执行,但是客户端 Y 的 DECR 命令就执行了,此时,a:stock 的值会被修改,这就无法保证 X 发起的事务的隔离性了。

刚刚说的是并发操作在 EXEC 命令前执行的情况,下面我再来说一说第二种情况:兵法操作在EXEC命令之后被服务器接受并执行

因为 Redis 是用单线程执行命令,而且,EXEC 命令执行后,Redis 会保证先把命令队列中的所有命令执行完。所以,在这种情况下,并发操作不会破坏事务的隔离性。

持久性

因为 Redis 是内存数据库,所以,数据是否持久化保存完全取决于 Redis 的持久化配置模式。

如果 Redis 没有使用 RDB 或 AOF,那么事务的持久化属性肯定得不到保证。如果 Redis 使用了 RDB 模式,那么,在一个事务执行后,而下一次的 RDB 快照还未执行前,如果发生了实例宕机,这种情况下,事务修改的数据也是不能保证持久化的。

如果 Redis 采用了 AOF 模式,因为 AOF 模式的三种配置选项 no、everysec 和 always 都会存在数据丢失的情况,所以,事务的持久性属性也还是得不到保证。

所以,不管 Redis 采用什么持久化模式,事务的持久性属性是得不到保证的。

总结

Redis 通过 MULTI、EXEC、DISCARD 和 WATCH 四个命令来支持事务机制,这 4 个命令的作用,我总结在下面的表中,你可以再看下。

事务的 ACID 属性是我们使用事务进行正确操作的基本要求。Redis 的事务机制可以保证一致性和隔离性,但是无法保证持久性。不过,因为 Redis 本身是内存数据库,持久性并不是一个必须的属性,我们更加关注的还是原子性、一致性和隔离性这三个属性。

Redis的ACID属性的更多相关文章

  1. Redis 中的事务分析,Redis 中的事务可以满足ACID属性吗?

    Redis 中的事务 什么是事务 1.原子性(Atomicity) 2.一致性(Consistency) 3.隔离性(Isolation) 4.持久性(Durability) 分析下 Redis 中的 ...

  2. 关于Redis的ACID

    事务是一个数据库必备的元素,对于redis也不例外,对于一个传统的关系型数据库来说,数据库事务满足ACID四个特性: A代表原子性:一个事务(transaction)中的所有操作,要么全部完成,要么全 ...

  3. 事务的ACID属性,图解并发事务带来问题以及事务的隔离级别

    事务的概述 事务是指作为单个逻辑工作单元执行的一系列操作,要么完全地执行,要么完全地不执行. 事务处理可以确保除非事务性单元内的所有操作都成功完成,否则不会永久更新面向数据的资源.通过将一组相关操作组 ...

  4. 14.2 事务的ACID属性

    14.2 事务的ACID属性正在更新内容.请稍后

  5. 数据库事务 ACID属性、数据库并发问题和四种隔离级别

    数据库事务 ACID属性.数据库并发问题和四种隔离级别 数据库事务 数据库事务是一组逻辑操作单元,使数据从一种状态变换到另一种状态 一组逻辑操作单元:一个或多个DML操作 事务处理原则 保证所有事务都 ...

  6. 华为云企业级Redis揭秘第16期:超越开源Redis的ACID"真"事务

    摘要: 开源Redis只支持伪事务,应用场景受限.高斯Redis发布企业级事务特性,支持完备ACID,为交易.库存等上层业务带来全新可能. 本文分享自华为云社区<华为云企业级Redis揭秘第16 ...

  7. SQL Server 中的 ACID 属性

    SQL Server 中的事务是什么? SQL Server 中的事务是一组被视为一个单元的 SQL 语句,它们按照"做所有事或不做任何事"的原则执行,成功的事务必须通过 ACID ...

  8. Redis学习 - 配置属性:bind

    bind这个属性很容易理解成限制可以访问的IP地址,其实是指Redis服务器可以选择监听来自哪个网卡的访问请求.我们再用的时候一般都只有一个网卡,所以只能写本机的IP地址或者回路地址.否则在启动服务器 ...

  9. 数据库的 ACID 属性

    ACID(Atomicity 原子性.Consistency 一致性.Isolation 隔离性.Durability 持久性)是一系列属性. 这些属性保证了数据库事物的可靠.在数据库中,对数据的一系 ...

随机推荐

  1. 如何无缝迁移 SpringCloud/Dubbo 应用到 Serverless 架构

    作者 | 行松 阿里巴巴云原生团队 本文整理自<Serverless 技术公开课>,"Serverless"公众号后台回复"入门",即可获取系列文章 ...

  2. 题解 CF1119H Tripe题解

    题目传送门 题目大意 给出\(n,t,x,y,z\),值域\(\le 2^t\),给出\(n\)个三元组\((a_i,b_i,c_i)\),表示有\(x\)个\(a_i\),\(y\)个\(b_i\) ...

  3. Python中is与==区别

    1.在Python中,id是什么?id是内存地址,那就有人问了,什么是内存地址呢? 你只要创建一个数据(对象)那么都会在内存中开辟一个空间,将这个数据临时加在到内存中,那么这个空间是有一个唯一标识的, ...

  4. Java(8)详解Random使用

    作者:季沐测试笔记 原文地址:https://www.cnblogs.com/testero/p/15201556.html 博客主页:https://www.cnblogs.com/testero ...

  5. 更好的 java 重试框架 sisyphus 背后的故事

    sisyphus 综合了 spring-retry 和 gauva-retrying 的优势,使用起来也非常灵活. 今天,让我们一起看一下西西弗斯背后的故事. 情景导入 简单的需求 产品经理:实现一个 ...

  6. 好程序员打造核心教培天团,着力培养IT高级研发人才

    随着数字化进程加快,各行各业数字化转型迫在眉睫,技术人才战略成为企业发力重点,IT高级研发人才已经成为企业的"核心资产",对企业发展起关键性作用,然而市场上高级研发人才极为稀缺.据 ...

  7. 人人都写过的5个Bug!

    大家好,我是良许. 计算机专业的小伙伴,在学校期间一定学过 C 语言.它是众多高级语言的鼻祖,深入学习这门语言会对计算机原理.操作系统.内存管理等等底层相关的知识会有更深入的了解,所以我在直播的时候, ...

  8. 2021.8.6考试总结[NOIP模拟32]

    T1 smooth 考场上水个了优先队列多带个$log$,前$80$分的点跑的飞快,后面直接萎了. 其实只需开$B$个队列,每次向对应队列中插入新的光滑数,就能保证队列中的数是单调的. 为了保证不重, ...

  9. 你知道怎么使用Google两步验证保护账户安全吗?

    目录 为什么我们需要使用它? 对有些人来说,盗取密码比您想象的更简单 什么是Google两步验证? 多一道安全防线 什么是Google Authenticator ? 使用Google两步验证的好处 ...

  10. netty系列之:搭建客户端使用http1.1的方式连接http2服务器

    目录 简介 使用http1.1的方式处理http2 处理TLS连接 处理h2c消息 发送消息 总结 简介 对于http2协议来说,它的底层跟http1.1是完全不同的,但是为了兼容http1.1协议, ...