Redis：事务（transaction）

关于“Redis事务”

Redis 中的事务（transaction）是一组命令的集合，至少是两个或两个以上的命令，Redis 事务保证这些命令被执行时中间不会被任何其他操作打断。

事务可以一次执行多个命令， 并且带有以下两个重要的保证：

1. 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
2. 事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

当使用 AOF 方式做持久化的时候，Redis 会使用单个 write(2) 命令将事务写入到磁盘中。然而，如果 Redis 服务器因为某些原因被管理员杀死，或者遇上某种硬件故障，那么可能只有部分事务命令会被成功写入到磁盘中：
1、如果 Redis 在重新启动时发现 AOF 文件出了这样的问题，那么它会退出，并汇报一个错误。
2、使用 redis-check-aof 程序可以修复这一问题：它会移除 AOF 文件中不完整事务的信息，确保服务器可以顺利启动。

从 2.2 版本开始，Redis 还可以通过乐观锁（optimistic lock）实现 CAS （check-and-set）操作。

【关于：“不支持回滚，不保证原子性”】

单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以“Redis 事务的执行并不是原子性的”：

事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做。

即：【不支持回滚，不保证原子性】（支持回滚的复杂操作会使 Redis 放弃其简单高效的特性）

如：

redis 127.0.0.1:7000> multi
OK
redis 127.0.0.1:7000> set a aaa
QUEUED
redis 127.0.0.1:7000> set b bbb
QUEUED
redis 127.0.0.1:7000> set c ccc
QUEUED
redis 127.0.0.1:7000> exec
1) OK
2) ERR - . . .
3) OK

如果 exec 在执行 set b bbb 处失败，set a 已成功不会回滚，set c 还会继续执行。

【关于：“原子操作”和“原子性”】

Redis 事务是一个原子操作，即：“事务中的命令要么全部被执行，要么全部都不执行”。

开启了事务之后：如果没有成功执行 EXEC，那么事务中的所有命令都不会被执行；如果成功执行 EXEC，那么事务中的所有命令都会被执行。

Redis 事务并不能保证操作的“原子性”，即：“该成功的成功，该失败的失败”。

Redis 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。

事务命令

一个事务从开始到执行会经历以下三个阶段：

1. 开始事务。
2. 命令入队。
3. 执行/放弃事务。

而 MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事务的基础：

Redis事务命令

命令	描述
MULTI	标记一个事务块的开始。 它总是返回 OK。 客户端可以继续向服务器发送任意多条命令，所有传入的命令都会返回一个内容为 QUEUED 的状态回复（status reply）。 这些命令被放到一个队列中，当 EXEC 命令被调用时，队列中的所有命令才会被按序执行。
EXEC	执行所有事务块内的命令。 如果没有成功执行 EXEC（因为断线等），那么事务中的所有命令都不会被执行；如果成功执行 EXEC，那么事务中的所有命令都会被执行。 其回复是一个数组，数组中的每个元素都是执行事务中的命令所产生的回复（回复元素的先后顺序和命令发送的先后顺序一致）。
DISCARD	取消事务，放弃执行事务块内的所有命令。 事务队列会被清空，并且客户端会从事务状态中退出。
WATCH key [key ...]	监视一个（或多个) key ，如果在事务执行之前这个（或这些) key 被其他命令所改动，那么事务将被打断。 事务只能在所有被监视键都没有被修改的前提下执行，如果这个前提不能满足的话，事务就不会被执行。
UNWATCH	取消 WATCH 命令对所有 key 的监视。

示例

1. 示例1：以 MULTI 开始一个事务， 然后将多个命令入队到事务中， 最后由 EXEC 命令触发事务， 一并执行事务中的所有命令：

   redis 127.0.0.1:6379> MULTI
   OK
   
   redis 127.0.0.1:6379> SET book-name "Mastering C++ in 21 days"
   QUEUED
   
   redis 127.0.0.1:6379> GET book-name
   QUEUED
   
   redis 127.0.0.1:6379> SADD tag "C++" "Programming" "Mastering Series"
   QUEUED
   
   redis 127.0.0.1:6379> SMEMBERS tag
   QUEUED
   
   redis 127.0.0.1:6379> EXEC
   1) OK
   2) "Mastering C++ in 21 days"
   3) (integer) 3
   4) 1) "Mastering Series"
      2) "C++"
      3) "Programming"
   

2. 示例二：执行 DISCARD 命令时， 事务会被放弃， 事务队列会被清空， 并且客户端会从事务状态中退出：

   redis> SET foo 1
   OK
   
   redis> MULTI
   OK
   
   redis> INCR foo
   QUEUED
   
   redis> DISCARD
   OK
   
   redis> GET foo
   "1"
   

事务中的错误

事务情况【？？？】

Redis 事务不支持回滚，如果遇到问题，会继续执行余下的命令。

• 只有语法错误，Redis 才会执行失败。

正常情况：

1. MULTI：用MULTI命令告诉Redis，接下来要执行的命令你先不要执行，而是把它们暂时存起来 【开启事务】
2. SADD "user1" 2：第一条命令进入等待队列【命令入队】
3. SADD "user2" 1：第二条命令进入等待队列【命令入队】
4. EXEC：告知redis执行前面发送的两条命令【提交事务】

异常情况：【？？？】

1. MULTI：正常命令
2. SET key value：正常命令
3. SET key：命令语法错误
4. EXEC：无法执行事务，那么第一条正确的命令也不会执行，所以key的值不会设置成功

例外情况：

1. MULTI：正常命令
2. SET key v1：正常命令
3. INCR key：此命令错误，字符串不能自增
4. EXEC：
   1. 事务依然提交了，key的值被设置为v1，自增操作执行失败，但整个事务没有回滚
   2. 可以放弃事务：discard

放弃情况：

1. MULTI：开启事务
2. SET age 25：命令入队
3. SET age 30：命令入队
4. DISCARD：放弃事务，则命令队列不会被执行

Redis事务复杂情况实现

悲观锁

悲观锁（Pessimistic Lock）：每次去拿数据的时候都认为别人会修改该数据，所以每次在拿数据的时候都会先上锁，这样别人想拿这个数据就会 block 阻塞直到它拿到锁。

• 传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁，让别人无法操作该数据。

乐观锁

乐观锁（Optimistic Lock）：每次去取数据的时候都认为别人不会修改该数据，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这条数据，一般使用版本号机制（类比于MySQL的“MVCC”）进行判断。

• 乐观锁适用于多读的应用类型，这样可以提高吞吐量。
• 乐观锁大多数情况是基于数据版本号（version）的机制实现的：为数据增加一个版本标识。

  在基于数据库表的版本解决方案中，一般是通过为数据库表添加一个“version”字段来实现读取出数据时，将此版本号一同读出，之后更新时，对此版本号加 1。此时，将提交数据的版本号与数据库表对应记录的当前版本号进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据，不予更新。

乐观锁实现举例：

文件:乐观锁实现举例.png

watch 机制实现乐观锁

监视一个（或多个）key ，如果在事务exec执行之前这个（或这些）key 被其他命令所改动，那么事务将被打断。

示例：

1. set k1 1：设置 k1 值为 1；
2. watch k1：监视 k1；【开始监视 k1，则其他客户端或事务不能修改 k1 的值】
3. set k1 2：设置 k1 值为 2；
4. multi：开始事务；
5. set k1 3：修改 k1 值为 3；
6. exec：提交事务；

如上，k1 的值仍然是 2，而不会被修改为 3，因为在事务开启之前 k1 的值被修改了；