1 事务原理

Redis 的事务包含如下命令：

序号命令及描述1MULTI 标记一个事务块的开始。2EXEC 执行所有事务块内的命令。3DISCARD 取消事务，放弃执行事务块内的所有命令。4WATCH key [key ...] 监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。5UNWATCH 取消 WATCH 命令对所有 key 的监视。

事务包含三个阶段：

1. 事务开启，使用 MULTI , 该命令标志着执行该命令的客户端从非事务状态切换至事务状态 ；

2. 命令入队，MULTI 开启事务之后，客户端的命令并不会被立即执行，而是放入一个事务队列 ；

3. 执行事务或者丢弃。如果收到 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 事务原子性的理解如下：

1. 命令入队时报错， 会放弃事务执行，保证原子性；

2. 命令入队时正常，执行 EXEC 命令后报错，不保证原子性；

也就是：Redis 事务在特定条件下，才具备一定的原子性 。

2.2 隔离性

数据库的隔离性是指：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。

事务隔离分为不同级别 ，分别是：

• 未提交读（read uncommitted）

• 提交读（read committed）

• 可重复读（repeatable read）

• 串行化（serializable）

首先，需要明确一点：Redis 并没有事务隔离级别的概念。这里我们讨论 Redis 的隔离性是指：并发场景下，事务之间是否可以做到互不干扰。

我们可以将事务执行可以分为 EXEC 命令执行前和 EXEC 命令执行后两个阶段，分开讨论。

1. EXEC 命令执行前

在事务原理这一小节，我们发现在事务执行之前 ，Redis key 依然可以被修改。此时，可以使用 WATCH 机制来实现乐观锁的效果。

1. EXEC 命令执行后

因为 Redis 是单线程执行操作命令， EXEC 命令执行后，Redis 会保证命令队列中的所有命令执行完 。 这样就可以保证事务的隔离性。

2.3 持久性

数据库的持久性是指 ：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

Redis 的数据是否持久化取决于 Redis 的持久化配置模式 。

1. 没有配置 RDB 或者 AOF ，事务的持久性无法保证；

2. 使用了 RDB模式，在一个事务执行后，下一次的 RDB 快照还未执行前，如果发生了实例宕机，事务的持久性同样无法保证；

3. 使用了 AOF 模式；AOF 模式的三种配置选项 no 、everysec 都会存在数据丢失的情况 。always 可以保证事务的持久性，但因为性能太差，在生产环境一般不推荐使用。

综上，redis 事务的持久性是无法保证的 。

2.4 一致性

一致性的概念一直很让人困惑，在我搜寻的资料里，有两类不同的定义。

1. 维基百科

我们先看下维基百科上一致性的定义：

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 事务在执行过程中符合数据库的约束，没有包含非法或者无效的错误数据。