Redis 的事务仅保证了数据的一致性，不具有像 DBMS 一样的 ACID 特性。
- 这组命令中的某些命令的执行失败不会影响其它命令的执行，不会引发回滚，即不具备原子性。
- 这组命令通过乐观锁机制实现了简单的隔离性，没有复杂的隔离级别。
- 这组命令的执行结果是被写入到内存的，是否持久取决于 Redis 的持久化策略，与事务无关。
Redis 事务实现
事务通过三个命令进行控制。
- multi：开启事务（开启事务成功后返回OK，并且端口后会出现(TX)字样，之后每一条命令都会进入事务而不会立即执行。）
- exec：执行事务（执行事务会将开启事务后所执行的全部命令全部执行，并一次性返回所有执行命令的结果。）
- discard：取消事务（如果取消事务而不是执行事务，则事务后所有执行的命令都会被取消而不会执行，执行后返回OK。）
基本使用
# 开启事务并执行
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set age 18
QUEUED
127.0.0.1:6379(TX)> incr age
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) (integer) 19
127.0.0.1:6379> get age
"19"
# 开启事务但是需要取消
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set name dabao
QUEUED
127.0.0.1:6379(TX)> set name erbao
QUEUED
127.0.0.1:6379(TX)> discard
OK
127.0.0.1:6379> get name
(nil)
Redis 事务异常处理
- 语法错误（比如少给了命令的固定参数），当事务中的命令出现语法错误时，整个事务在 exec 执行时都会被取消而不会执行。
- 执行异常（比如给了命令错误的参数类型），如果事务中的命令没有语法错误，但在执行过程中出现异常，该异常不会影响其它命令的执行。
事务异常的结果示例
# 语法错误，incrby命令少了固定参数，所以执行exec也会直接报错从而取消整个事务
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set age 18
QUEUED
127.0.0.1:6379(TX)> incrby age
(error) ERR wrong number of arguments for 'incrby' command
127.0.0.1:6379(TX)> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get age
"19"
# 执行异常，可以看到执行异常中途并不会报错，只会在最后执行的时候该条命令的错误信息，并且不影响其它命令的正常执行。
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set age 18
QUEUED
127.0.0.1:6379(TX)> set name dabao
QUEUED
127.0.0.1:6379(TX)> incr name
QUEUED
127.0.0.1:6379(TX)> incr age
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) OK
3) (error) ERR value is not an integer or out of range
4) (integer) 19
127.0.0.1:6379> get age
"19"
127.0.0.1:6379> get name
"dabao"
127.0.0.1:6379>
Redis 事务隔离机制
为什么需要隔离机制？
在并发场景下可能会出现多个客户端对同一个数据进行修改的情况。
例如：有两个客户端 A 与 B，A 需要申请 40 个资源，B 需要申请 30 个资源。它们首先查看了当前拥有的资源数量，即 resources 的值。它们查看到的都是 50，都感觉资源数量可以满足自己的需求，于是修改资源数量，以占有资源。但结果却是资源出现了“超卖”情况。示例如下：
为了解决这种情况，Redis 事务通过乐观锁机制实现了多线程下的执行隔离。
隔离的实现
Redis 通过 watch 命令再配合事务实现了多线程下的执行隔离。
示例：
以上两个客户端执行的时间顺序为：
实现原理
其内部的执行过程如下：
- 当某一客户端对 key 执行了 watch 后，系统就会为该 key 添加一个 version 乐观锁，并初始化 version。例如初值为 1.0。
- 此后客户端 C 左将对该 key 的修改语句写入到了事务命令队列中，虽未执行，但其将该key 的 value 值与 version 进行了读取并保存到了当前客户端缓存。此时读取并保存的是version 的初值 1.0。
- 此后客户端 C 右对该 key 的值进行了修改，这个修改不仅修改了 key 的 value 本身，同时也增加了 version 的值，例如使其 version 变为了 2.0，并将该 version 记录到了该 key信息中。
- 此后客户端 C 左执行 exec，开始执行事务中的命令。不过，其在执行到对该 key 进行修改的命令时，该命令首先对当前客户端缓存中保存的 version 值与当前 key 信息中的version 值。如果缓存 version 小于 key 的 version，则说明客户端缓存的 key 的 value 已经过时，该写操作如果执行可能会破坏数据的一致性。所以该写操作不执行。