31 Redis 的事务机制

  • 前言
  • 一、事务 ACID 属性的要求
  • 二、 Redis 如何实现事务？
  • 三、Redis 的事务机制能保证哪些属性？
    • 原子性
    • 一致性
    • 隔离性
    • 持久性
  • 总结

前言

事务在执行时会提供专门的属性保证，包括原子性（Atomicity）、一致性 （Consistency）、隔离性（Isolation）和持久性（Durability），也就是 ACID 属性。这些属性既包括了对事务执行结果的要求，也有对数据库在事务执行前后的数据状态变化的要求。

Redis 中如果有些属性在一些场景下不能保证的话，很可能会导致数据出错，所以要掌握 Redis 对这些属性的支持情况，并且提前准备应对策略。

一、事务 ACID 属性的要求

原子性：是一个事务中的多个操作必须都完成，或者都不完成。业务应用使用事务时，原子性也是最被看重的一个属性。 假如用户在一个订单中购买了两个商品 A 和 B，那么数据库就需要把这两个商品的库存都进行扣减。如果只扣减了一个商品的库存，这个订单完成后， 另一个商品的库存肯定就错了。

一致性：是指数据库中的数据在事务执行前后是一致的。

隔离性：要求数据库在执行一个事务时，其它操作无法存取到正在执行事务访问的数据。假设商品 A 和 B 的现有库存分别是 5 和 10，用户 X 对 A、B 下单的数量分别是 3、6。如果事务不具备隔离性，在用户 X 下单事务执行 的过程中，用户 Y一下子也购买了 5 件 B，这和 X 购买的 6 件 B 累加后，就超过 B 的总库存值了。

持久性：数据库执行事务后，数据的修改要被持久化保存下来。当数据库重启后，数据的值需要是被修改后的值。

二、 Redis 如何实现事务？

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

  1. 客户端要使用一个命令显式地表示一个事务的开启。在 Redis 中这个命令就是 MULTI。
  2. 客户端把事务中本身要执行的具体操作（例如增删改数据）发送给服务器端。Redis 本身提供的数据读写命令，例如 GET、SET 等。不过这些命令虽然被客户端发送到了服务器端，但 Redis 实例只是把这些命令暂存到一个命令队列中，并不会立即执行。
  3. 客户端向服务器端发送提交事务的命令，让数据库实际执行第二步中发送的具体操作。Redis 提供的 EXEC 命令就是执行事务提交的。当服务器端收到 EXEC 命令后，才会实际执行命令队列中的所有命令。

使用 MULTI 和 EXEC 执行一个事务的过程。

#开启事务
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 命令已经成功地执行了。

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

原子性

如果事务正常执行，没有发生任何错误，那么 MULTI 和 EXEC 配合使用，就可以保证多个操作都完成。但是如果事务执行发生错误了，原子性还能保证吗？需要分三种情况来看：

第一种情况： 在执行 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 命令后，整个事务被放弃执行了。

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

例如事务中的 LPOP 命令对 String 类型数据进行操作，入队时没有报错，但在 EXEC 执行时报错了。LPOP 命令本身没有执行成功，但是事务中的 DECR 命令却成功执行了。

#开启事务
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 命令，但是这个命令只能用来主动放弃事务执行，把暂存的命令队列清空，起不到回滚的效果。

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"

a:stock 键的值一开始为 4，然后执行一个事务，想对 a:stock 的值减 1。但是在事务的最后，执行的是 DISCARD 命令，所以事务就被放弃了。再次查看 a:stock 的值仍然为 4。

第三种情况： 在执行事务的 EXEC 命令时，Redis 实例发生了故障， 导致事务执行失败。如果 Redis 开启了 AOF 日志，那么只会有部分的事务操作被记录到 AOF 日志中。需要使用 redis-check-aof 工具检查 AOF 日志文件，这个工具可以把已完成的事务操作从 AOF 文件中去除。使用 AOF 恢复实例后，事务操作不会再被执行，从而保证了原子性。

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

Redis 对事务原子性属性的保证情况：

  • 命令入队时就报错，会放弃事务执行，保证原子性；
  • 命令入队时没报错，实际执行时报错，不保证原子性；
  • EXEC 命令执行时实例故障，如果开启了 AOF 日志，可以保证原子性。

一致性

事务的一致性保证会受到错误命令、实例故障的影响。所以按照命令出错和实例故障的发生时机，分成三种情况：

  1. 命令入队时就报错：事务本身就会被放弃执行，所以可以保证数据库的一致性。
  2. 命令入队时没报错，实际执行时报错：有错误的命令不会被执行，正确的命令可以正常执行，也不会改变数据库的一致性。
  3. 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 命令实现的：

在 t1 时，客户端 X 向实例发送了 WATCH 命令。实例收到 WATCH 命令后，开始监测 a:stock 的值的变化情况。
在 t2 时，客户端 X 把 MULTI 命令和 DECR 命令发送给实例，实例把 DECR 命令暂存入命令队列。
在 t3 时，客户端 Y 也给实例发送了一个 DECR 命令，要修改 a:stock 的值，实例收到命令后就直接执行了。 等到 t4 时，实例收到客户端 X 发送的 EXEC 命令，但是实例的 WATCH 机制发现 a:stock 已经被修改了，就会放弃事务执行。这样事务的隔离性就可以得到保证了。

当然如果没有使用 WATCH 机制，在 EXEC 命令前执行的并发操作是会对数据进行读写的。而且在执行 EXEC 命令的时候，事务要操作的数据已经改变了，在这种情况下 Redis 并没有做到让事务对其它操作隔离，隔离性也就没有得到保障。

没有 WATCH 机制时的情况：

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

第二种情况： 并发操作在 EXEC 命令之后被服务器端接收并执行。因为 Redis 是用单线程执行命令，而且EXEC 命令执行后，Redis 会保证先把命令队列中的所有命令执行完。所以并发操作不会破坏事务的隔离性，如下图：

持久性

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

  • 如果 Redis 没有使用 RDB 或 AOF，那么事务的持久化属性肯定得不到保证。如果 Redis 使用了 RDB 模式，那么在一个事务执行后，而下一次的 RDB 快照还未执行前，如果发生了实例宕机，事务修改的数据也是不能保证持久化的。
  • 如果 Redis 采用了 AOF 模式，因为 AOF 模式的三种配置选项 no、everysec 和 always 都会存在数据丢失的情况，所以事务的持久性属性也还是得不到保证。

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

总结

Redis 中的事务实现：Redis 通过 MULTI、EXEC、DISCARD 和 WATCH 四个命令来支持事务机制：

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

原子性的情况比较复杂，只有当事务中使用的命令语法有误时，原子性得不到保证，在其它情况下，事务都可以原子性执行。建议：严格按照 Redis 的命令规范进行程序开发，并且通过 code review 确保命令的正确性。这样 Redis 的事务机制就能被应用在实践中，保证多操 作的正确执行。

31 Redis 的事务机制相关推荐

  1. Redis的事务机制

    文章目录 一.事务演示 二.事务实现原理 2.1 事务开始 2.2 命令入队 2.3 事务执行 三.WATCH命令的实现原理 3.1 使用WATCH命令监视数据库键 3.2 监视机制的触发 3.3 判 ...

  2. Redis教程–事务机制基本介绍

    摘要:Redis是一个简单.高效的内存数据存储,支持多种数据结构.当然,有数据操作的地方往往都少不了事务性,Redis是否支持呢?答案是肯定的.本文将详细讲述如何redis事务使用相关的内,如有错误, ...

  3. redis的事务机制详解

    一.Redis的事务定义 Redis事务是一个单独的隔离操作:事务中的所有命令都会序列化.按顺序地执行.事务在执行的过程中,不会被其他客户端发送来的命令请求所打断. Redis事务的主要作用就是串联多 ...

  4. Redis学习笔记~Redis事务机制与Lind.DDD.Repositories.Redis事务机制的实现

    回到目录 Redis本身支持事务,这就是SQL数据库有Transaction一样,而Redis的驱动也支持事务,这在ServiceStack.Redis就有所体现,它也是目前最受业界认可的Redis驱 ...

  5. Redis事务机制 -Redis 核心技术与实战

    事务是数据库的一个重要功能.所谓的事务,就是指对数据进行读写的一系列操作.事务在执行时,会提供专门的属性保证,包括` 原子性(Atomicity) 一致性(Consistency) 隔离性(Isola ...

  6. Redis实战 - 15 Redis事务机制和乐观锁实现

    文章目录 1. Redis事务简介 2. Redis事务的操作命令 3. Redis的事务回滚 4. Redis监控事务 1. Redis事务简介 在 Redis 中,也存在多个客户端同时向 Redi ...

  7. redis的事务不是原子性

    一.事务的四大特性 关系型数据库的事务具有四个特性: 1. 原子性 2. 一致性 3. 隔离性 4. 持久性 二.而在我们redis数据库中,事务回事什么样子的呢? 首先我们给出一个定义:redis的 ...

  8. Redis原理和机制详解

    什么是Redis? Redis 是开源免费的,遵守BSD协议,是一个高性能的key-value非关系型数据库. Redis特点: Redis支持数据的持久化,可以将内存中的数据保存在磁盘中,重启的时候 ...

  9. 图解Redis事务机制

    来自:Java中文社群 作为关系型数据库中一项非常重要的基础功能--事务,在 Redis 中是如何处理并使用的? 1.前言 事务指的是提供一种将多个命令打包,一次性按顺序地执行的机制,并且保证服务器只 ...

最新文章

  1. python3 zipfile_python3中zipfile模块的常用方法
  2. iOS 9应用开发教程之使用开关滑块控件以及滚动部署视图
  3. app后端设计（php）
  4. 行业指数动量策略+akshare
  5. 《Windows Server 2012 Hyper-V虚拟化管理实践》——2.3　Hyper-V角色安装后的状态
  6. 个税抵扣全指南精华版！
  7. Centos 7 Mysql 配置文件位置
  8. 高级工具 zeppelin 整合hive教程
  9. 12x12怎么速算_12x12怎样巧算
  10. PS打不开webp格式图片的解决方法
  11. GeForce Experience 绕过登录与禁止自动更新
  12. 使用CityBuilder搭建智慧城市3D可视化模型
  13. 3分钟看懂：7大教育培训企业邮件营销 （附案例）
  14. 【雕爷学编程】Arduino动手做（103）---四路无线遥控套件
  15. 【愚公系列】2023年01月 Java教学课程 001-Java语言背景介绍
  16. 常用ASP代码加密工具的工作原理
  17. [网鼎杯 2020 朱雀组]phpweb
  18. DSS：(Decision-making Support System)决策支持系统
  19. 面向对象方法学与结构化方法学的异同
  20. 2019中国（北京）国际智慧建筑装备展览会

热门文章

  1. Lotus API生成令牌
  2. 【数据采集】python爬虫进阶学习——聚焦爬虫（纯干货）
  3. 钱究竟是什么东西(三)-货币供应量
  4. ipdb调试命令简介
  5. linux shell dirname $0是什么意思
  6. 西藏自治区计算机等级考试官网,西藏计算机等级考试报名
  7. 《成吉思汗与今日世界之形成》--读后感
  8. iOS照相机获取到的图片自动旋转90度解决办法
  9. 程序员如何用物联网赚钱？
  10. 后台进程启动Activity