目录
1、何为事务机制？
Transaction（事务）是计算机的特有术语，它一般指单个逻辑工作单位，由一系列的操作组合而成，在这些操作执行的时候，要么都执行成功，要么都不执行，防止数据结果的不一致性。
简而言之，事务是一个不可分割的工作逻辑单位。为了衡量工作单元是否具备事务能力，需要满足四个特征：ACID，即 原子性（Atomicity，或称不可分割性）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）。
- 原子性（Atomicity）：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
- 一致性（Consistency）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的数据必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
- 实体完整性，存在唯一的主键
- 列完整性:字段类型、字段长度等符合所有的预设规则
- foreign key 外键约束
- 用户自定义完整性（如用户购物支付前后，商家收入和用户的余额总和不变）
- 隔离性（Isolation）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
- 持久性（Durability）：事务处理结束后，对数据的修改就是永久的，会持久化到硬盘上，即便系统故障也不会丢失。
2、为什么需要使用事务
以支付场景为例，A向B支付100元，需要在A的账户中扣去100元，在B的账户中增加100元。这两个操作如果其中一个操作成功，另一个操作失败，就会导致问题。比如A付了钱B没有收到，或者A没付钱B收到了。我们可以使用事务将这两个操作变成一个原子性操作，要么一起成功，要么都不成功。
Redis的单个命令是原子性的（比如 get 、set、mget、mset），要么成功要么失败，不存在并发干扰的问题。
如果涉及到多个命令的时候，需要把多个命令作为一个不可分割的处理序列，就必须要依赖Redis的功能特性来实现了。
Redis提供了事务的功能，可以把一组命令一起执行。Redis的事务有3个特点：
- 按进入队列的顺序执行。
- 不会受到其他客户端的请求的影响。
- 事务不能嵌套，多个multi命令效果一样。
3、Redis模式下如何实现事务机制？
Redis的事务涉及到四个命令：multi（开启事务），exec（执行事务），discard（取消事务），watch（监视）。
- MULTI 开启事务，总是返回OK
- EXEC 提交事务
- DISCARD 放弃事务（即放弃提交执行）
- WATCH 监控
- QUEUED 命令加入执行的队列，没操作一个动作的时候，都先加入Queue
根据上述命令，Redis 事务的执行过程包含三个步骤：
- 开启事务：MULTI
- 命令入队：QUEUE
- 执行事务或丢弃：EXEC 或者 DISCARD
示例演示：fan和cai各有1000元，fan向cai转账100元。
127.0.0.1:6379> set fan 1000
OK
127.0.0.1:6379> set cai 1000
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby fan 100
QUEUED
127.0.0.1:6379> incrby cai 100
QUEUED
127.0.0.1:6379> exec
1) (integer) 900
2) (integer) 1100
127.0.0.1:6379> get fan
"900"
127.0.0.1:6379> get cai
"1100"
从上面可以看出来，每个读写指令执行后的返回结果都是 QUEUED，代表这些操作只是暂存在指令队列中，并没有实际执行。
当发送了 EXEC 命令之后，才真正执行并获取结果。
步骤
（1）Client 通过 MULTI 命令显式开启一个事务，随后执行的操作将会暂时缓存在Queue中，实际并没有立即执行。
（2）Client 端 把事务中的要执行的一系列操作指令发送到Service 端。 Redis服务端 实例接收到指令之后，并不是马上执行，而是暂存在命令队列中。
（3）当Client端向Service端发送的命令都Ready了之后，可以发送提交执行或者丢弃事务的命令，如果是执行则操作队列中的具体指令，如果是丢弃则是清空队列命令。
- EXEC：执行队列中的指令
- DISCARD：丢弃保存在队列中的命令
DISCARD命令：放弃事务
通过 MULTI 和 DISCARD 丢弃执行，清空指令队列：
127.0.0.1:6379> set fan 2000
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incrby fan 1000
QUEUED
127.0.0.1:6379> discard
OK
127.0.0.1:6379> get fan
"2000"
127.0.0.1:6379>
因为命令错误导致的事务回滚
体现原子性，再发生故障的时候，要么执行都成功，要么执行都失败
127.0.0.1:6379> set cai 2000
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> uuu cai 1000
(error) ERR unknown command 'uuu'
127.0.0.1:6379> decrby cai 500
QUEUED
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379>4、Redis事务机制能实现哪些属性？
类似MySQL的事务，Redis 事务一次性可以执行多个指令， 而这多个指令通过以下的方式来保证：
- EXEC 命令执行之前，所有的指令都是被暂存（Queued）在队列中；
- Service端接收到EXEC命令后开始执行事务，事务中某些命令执行失败，其余命令依旧执行；
- 在事务执行的时候具备隔离性，其他Client端执行的指令不会乱入到当前指令的执行顺序中的。
Redis事务机制可以实现以下三个属性：
-
原子性（Atomicity）：Redis事务中的一组命令要么全部执行成功，要么全部失败回滚，具有原子性。事务的所有操作要么全部提交，要么全部取消，保证了数据的一致性。如果在事务执行过程中出现错误，Redis会继续执行剩余的命令，但事务最终的结果会被标记为错误。
-
一致性（Consistency）：事务中的命令按照顺序依次执行，保持了命令执行的一致性。在事务执行期间，其他客户端提交的命令不会被插入到事务队列中，避免了并发操作对事务执行的干扰。
-
隔离性（Isolation）：Redis事务提供了隔离性，即事务执行过程中的修改对其他事务是不可见的。事务的隔离性可以防止并发操作引起的数据冲突和竞态条件，确保数据的正确性。
需要注意的是，Redis的事务机制并不支持持久性（Durability）属性。事务中的操作在提交之前只存在于内存中，如果服务器发生故障，事务可能会丢失。因此，在需要保证数据持久化的场景下，需要结合使用Redis的持久化机制（如RDB持久化或AOF持久化）来确保数据的安全性。
原子性（Atomicity）
在事务执行的过程中，可能遇到这几种命令执行错误：
- 在执行 EXEC 命令前，指令本身错误：
- 参数数量不一致构成的错误
- 命令名称构成的错误，使用了不存在或者错误的命令：比如上面的
- 超过MaxMemory内存限制，导致内存不足
- 在执行 EXEC 命令后，命令的不合理操作导致的失败。比如数据类型不匹配（对 String 类型 的 value 执行了 INCR 或者 DECR 之类的操作）
- 在执行事务的 EXEC 命令时，实例故障导致的失败，这种情况比较少一点。
EXEC 执行前报错
执行前错误是指命令入队（Queue）时，Redis 就会发现并记录报错。
即使执行了 EXEC命令之后，Redis也会拒绝执行指令队列中的所有指令，返回事务失败的结果。
这样一来，所有的指令都不会被执行，保持了原子性。下面是指令入队列的报错的实例，跟上面的举例一致：
# 开启事务
> MULTI
OK
# 初始一个数据
> SET 'age' 18
OK
# 对该数据进行更新，但Redis不支持该命令，返回报错信息
> UPD 'age' 17
(error) ERR unknown command `UPD`, with args beginning with: `age`, `17`,
# 继续发送一个指令 ，降低age的值，该指令是正确的
> DECR 'age'
QUEUED
# 执行exec，但是之前有错误，所以Redis放弃了事务，不再执行
> EXEC
(error) EXECABORT Transaction discarded because of previous errors.
EXEC 执行后报错
这个跟上面的情况正好相反，指令入Queue时，命令的类型虽然不匹配，但是并没有在预编译的时候检查出。
只有在EXEC 命令之后，实际执行指令的时候才会报错。其他正确的指令还是会执行成功，不保证原子性。 参考下面：
# 开启事务
> MULTI
OK
> set age 18
QUEUED
> set name 'brand'
QUEUED
> INCR age
QUEUED
# 这边对String类型进行DECR，没有报错，但是在执行指令的时候会报错误
> DECR name
QUEUED
# 执行，会发现其他三条执行执行成功，只有一条执行失败，返回报错信息
> EXEC
1) OK
2) OK
3) 19
4) ERR value is not an integer or out of range
# 查看结果
> get name
"brand"
> get age
"19"
在EXEC执行时发生实例故障
可以使用AOF日志，把未完成的事务操作从AOF日志中去除，之后使用AOF进行恢复时就不会被再次执行，以此保证整个操作的原子性。
这个需要Redis启用AOF日志这个持久化能力。
对于上述几种错误特征的总结
- 指令入队列时有报错（所有指令中只要有一条不是QUEUED），就会放弃事务执行，保证原子性。
- 指令入队列时没报错（所有指令都是QUEUED），但在实际执行EXEC时报错，则不保证原子性。
- EXEC执行时出现故障，如果开启了 AOF 日志，可以保证原子性。
一致性
跟原子性类似，一致性会受到错误指令、执行异常、Redis故障等情况的影响，主要有如下几种情况：
- 指令入队列时有报错，事务被放弃执行，所以可以保证一致性。
- 指令入队列时正产，实际执行EXEC时报错，则是错误部分不会执行，正确指令依旧正常执行，也可以保证一致性。
- Redis实例故障分成几种：
- 未开启持久化情况，故障重启后数据都清空，结果是一致的。
- RDB快照：事务命令操作的结果不被保存到 RDB 快照中，所以在恢复时，数据结果是一致的。
- AOF 日志：发生故障时，使用 redis-check-aof 清除事务中对应操作，数据库恢复后也保持一致。
隔离性
从隔离性这个角度，事务执行的时机可以分成两种：
- 一种是操作在EXEC执行之前（纯入队期间），这时候采用 WATCH 的机制来保障
- 另一种是开始执行EXEC之后（实际开始执行命令了），这时候本身具备隔离性了。
WATCH监测对象是否有变化
如果前后有变化，说明被修改了，这时就放弃事务执行，避免事务的隔离性被破坏。
对操作进行顺序，并发操作排在 EXEC 之后
Redis 操作命令是单线程执行的，所以在EXEC 命令执行后，不会乱入其他操作，Redis 会保证把指令队列中的所有指令都操作完成之后。
在执行后续的命令，所以，这种模式并发操作不会破坏事务的隔离性。它具有天然的隔离能力。
5、总结
因为Redis的持久化特性，所以有如下三种可能性：
- 未开启 RDB快照 或 AOF日志，事务肯定不具备持久化能力。
- RDB快照模式：我们在Redis持久化那一篇中聊过，RDB具有快照间隙，事务执行在快照之间则不会被保障。
- AOF日志：无论日志持久化选项是 no、everysec 和 always 都会存在数据丢失的情况，所以也是无法完全保障的。
所以不管 Redis 采用什么持久化模式，事务的持久性属性是得不到完全保证的。
- Redis 具备了一定的原子性，但不支持回滚。DISCARD 主要负责清空指令列表，放弃操作。
- Redis 具备一致性的能力
- Redis 具备隔离性的能力
- Redis 无法保证持久性