Redis中事务主要是通过MULTI、EXEC、DISCARD命令来实现事务的。事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而去执行其他客户端命令。
Redis事务的相关命令
1. MULTI
用于标记事务块的开始。Redis会将后续的命令逐个放入队列中，然后才能使用EXEC命令原子化地执行这个命令序列。
这个命令的运行格式如下所示：
MULTI
这个命令的返回值是一个简单的字符串，总是OK。
2. EXEC
在一个事务中执行所有先前放入队列的命令，然后恢复正常的连接状态。
当使用WATCH命令时，只有当受监控的键没有被修改时，EXEC命令才会执行事务中的命令，这种方式利用了检查再设置（CAS）的机制。
这个命令的运行格式如下所示：
EXEC
这个命令的返回值是一个数组，其中的每个元素分别是原子化事务中的每个命令的返回值。 当使用WATCH命令时，如果事务执行中止，那么EXEC命令就会返回一个Null值。
3. DISCARD
清除所有先前在一个事务中放入队列的命令，然后恢复正常的连接状态。
如果使用了WATCH命令，那么DISCARD命令就会将当前连接监控的所有键取消监控。
这个命令的运行格式如下所示：
DISCARD
这个命令的返回值是一个简单的字符串，总是OK。
4. WATCH
当某个事务需要按条件执行时，就要使用这个命令将给定的键设置为受监控的。
这个命令的运行格式如下所示：
WATCH KEY [KEY...]
这个命令的返回值是一个简单的字符串，总是OK。
对于每个键来说，时间复杂度总是O(1)。
5. UNWATCH
清除所有先前为一个事务监控的键。
如果你调用了EXEC或DISCARD命令，那么就不需要手动调用UNWATCH命令。
这个命令的运行格式如下所示：
UNWATCH
这个命令的返回值是一个简单的字符串，总是OK。
Redis的事务的实现
1.事务主要经过3个阶段
1.1 事务开始 --------> mulit
1.2 命令入队 --------> get、set等操作命令
当一个客户端处于非事务状态时，这个客户端的命令会立即被服务器执行。与此不同的是，当一个客户端切换到事务状态之后，服务器会根据这个客户端发来的不同的命令执行不同的操作：
(2) 如果客户端发送的命令是 EXEC、 DISCARD、 WATCH、 MULTI四个命令以外的其他命令，那么服务器不会立即执行这个命令，而是将这个命令放在一个事务队列中，然后向客户端返回 QUEUED回复。
1.3 执行事务 --------> exec
2 事务队列
事务队列是一个以先进先出（FIFO）的方式保存入队的命令，较先入队的命令会被放到数组的前面，而较后入队的命令则会被放到数组的后面。例如：
那么服务器器将会为客户端创建一个事务队列，将上面4条命令入队，最先入队的SET命令放在事务队列的最前面……：
3执行事务
当一个处于事务状态的客户端向服务器发送EXEC命令时，这个EXEC命令将立即被服务器执行。服务器会遍历这个客户端的事务队列，执行队列中保存的所有的命令，最后将执行命令所得的结果返回给客户端。对于上例子：
WATCH命令的实现
WATCH命令是一个乐观所（optimistic locking），它可以在EXEC命令执行前，监视任意数量的数据库键，并在EXEC命令执行时，检查监视的键是否至少有一个已经被修改过了，如果修改过了，服务器将拒绝执行事务，并向客户端返回代表事务执行失败的空回复。例如，下面的事务将会执行失败：
1 127.0.0.1:6379>> WATCH name 2 OK 3 4 127.0.0.1:6379>> MULTI 5 OK 6 7 127.0.0.1:6379>> set "name" "Peter" 8 QUEUED 9 10 127.0.0.1:6379>> EXEC 11 (nil)
| 时间 | 客户端A | 客户端B |
|---|---|---|
| T1 | WATCH "name" | |
| T2 | MULTI | |
| T3 | SET "name" "Peter" | |
| T4 | SET "name" "jack" | |
| T5 | EXEC |
在时间T4，客户端B修改了"name"键的值，当客户端A在T5执行EXEC命令时，服务器会发现WATCH监视的键“name”已经被修改，因此服务器拒绝执行客户端A的事务，并向客户端A返回空回复。
2.1使用WATCH命令监视数据库键
每个Redis数据库保存着一个watched_keys字典，这个字典的键是某个被WATCH命令监视的数据库键，而字典的值是一个链表，链表记录了所有监视相应数据库键的客户端。
上图表明：
(1) 客户端c1和c2正在监视键“name”。
(2) 客户端c3正在监视键“age”。
(3) 客户端c2和c4正在监视键“address”。
2.2 监视机制的触发
所有对数据库进行修改命令，如SET、LPUSH、SADD、ZREM、DEL等，在执行后都会对watched_keys字典进行检查，查看被修改的数据库键是否是被客户端所监视的键，如果有的话，客户端REDIS_DIRTY_CAS标识将会被打开，表示该客户端的事务安全性已经被破坏。
2.3 判断事务是否安全
当服务器接收到一个客户端发来的EXEC命令，服务器会根据这个客户端是否打开了REDIS_DIRTY_CAS标识来决定是否执行事务：
事务的ACID性质
在Redis中，事务总是具有原子性（Atomicity）、一致性（Consistency）和隔离性（Isolation），并且当Redis运行在某种特定的持久化模式下，事务也具有耐久性（Durability）。
3.1 原子性
事务具有原子性指的是， 数据库将事务中的多个操作当作一个整体来执行，服务器要么就执行事务中的所有操作， 要么就一个操作也不执行。
对于Redis的事务功能来说，事务队列中的命令要么就全部都执行，要么就一个都不执行，因此， Redis的事务是具有原子性的。
下面是一个执行失败的事务，这个事务因为命令入队出错而被服务器拒绝执行：
1 127.0.0.1:6379> multi 2 OK 3 4 127.0.0.1:6379> set msg hello 5 QUEUED 6 7 127.0.0.1:6379> get 8 (error) ERR wrong number of arguments for 'get' command 9 10 127.0.0.1:6379> get msg 11 QUEUED 12 13 127.0.0.1:6379> exec 14 (error) EXECABORT Transaction discarded because of previous errors.
Redis的事务和传统的关系型数据库事务的最大区别在于，Redis不支持事务回滚机制(rollback)， 即使事务队列中的某个命令在执行期间出现了错误，整个事务也会继续执行下去，直到将事务队列中的所有命令都执行完毕为止。
下面展示了即使RPUSH命令在执行期间出现了错误，事务的后续命令也会继续执行下去， 并且之前执行的命令也不会有任何影响：
1 127.0.0.1:6379> set msg hello 2 OK 3 4 127.0.0.1:6379> multi 5 OK 6 7 127.0.0.1:6379> sadd fruit apple banana cherry 8 QUEUED 9 10 127.0.0.1:6379> rpush msg bye redis 11 QUEUED 12 13 127.0.0.1:6379> sadd alphabet a b c 14 QUEUED 15 16 127.0.0.1:6379> exec 17 1) (integer) 3 18 2) (error) WRONGTYPE Operation against a key holding the wrong kind of value 19 3) (integer) 3
Redis为什么不支持回滚：不支持事务回滚是因为这种复杂的功能和Redis追求简单高效的设计主旨不相符，并且Redis事务的执行时错误通常都是编程错误产生的， 这种错误通常只会出现在开发环境中， 而很少会在实际的生产环境中出现。
如果你具备关系型数据库的知识背景，你就会发现一个事实：在事务运行期间，虽然Redis命令可能会执行失败，但是Redis仍然会执行事务中余下的其他命令，而不会执行回滚操作，你可能会觉得这种行为很奇怪。
然而，这种行为也有其合理之处：
只有当被调用的Redis命令有语法错误时，这条命令才会执行失败（在将这个命令放入事务队列期间，Redis能够发现此类问题），或者对某个键执行不符合其数据类型的操作：实际上，这就意味着只有程序错误才会导致Redis命令执行失败，这种错误很有可能在程序开发期间发现，一般很少在生产环境发现。
Redis已经在系统内部进行功能简化，这样可以确保更快的运行速度，因为Redis不需要事务回滚的能力。对于Redis事务的这种行为，有一个普遍的反对观点，那就是程序有可能会有缺陷（bug）。但是，你应当注意到：事务回滚并不能解决任何程序错误。例如，如果某个查询会将一个键的值递增2，而不是1，或者递增错误的键，那么事务回滚机制是没有办法解决这些程序问题的。请注意，没有人能解决程序员自己的错误，这种错误可能会导致Redis命令执行失败。正因为这些程序错误不大可能会进入生产环境，所以我们在开发Redis时选用更加简单和快速的方法，没有实现错误回滚的功能。
3.2 一致性
事务的一致性是指，如果数据库执行前是一致的，那么在事务执行后，无论事务是否执行成功，数据库也应该是一致的。
3.2.1入队错误
如果一个事务在入队命令的过程中，出现了命令不存在，或者命令的格式不正确等情况， 那么Redis将拒绝执行这个事务。因为服务器会拒绝执行人队过程中出现错误的事务， 所以Redis事务的一致性不会被带有入队错误的事务影响。
1 127.0.0.1:6379> multi 2 OK 3 4 127.0.0.1:6379> set msg hello 5 QUEUED 6 7 127.0.0.1:6379> YAHOOO 8 (error) ERR unknown command 'YAHOOO' 9 10 127.0.0.1:6379> get msg 11 QUEUED 12 13 127.0.0.1:6379> exec 14 (error) EXECABORT Transaction discarded because of previous errors.
Redis 2.6.5以前的入队错误处理：Redis会忽略错误的命令，而正确的命令如上面的SET和GET仍然会被执行。
3.2.2 执行错误
执行错误通常都是一些不能在入队时被服务器发现的错误， 这些错误只会在命令实际执行时被触发。即使在事务的执行过程中发生了错误， 服务器也不会中断事务的执行， 它会继续执行事务中余下的其他命令， 并且已执行的命令（包括执行命令所产生的结果）不会被出错的命令影响。
因为在事务执行的过程中， 出错的命令会被服务器识别出来， 并进行相应的错误处理， 所以这些出错命令不会对数据库做任何修改， 也不会对事务的一致性产生任何影响。
1 127.0.0.1:6379> set msg hello 2 OK 3 4 127.0.0.1:6379> multi 5 OK 6 7 127.0.0.1:6379> sadd fruit apple banana cherry 8 QUEUED 9 10 127.0.0.1:6379> rpush msg bye redis 11 QUEUED 12 13 127.0.0.1:6379> sadd alphabet a b c 14 QUEUED 15 16 127.0.0.1:6379> exec 17 1) (integer) 3 18 2) (error) WRONGTYPE Operation against a key holding the wrong kind of value 19 3) (integer) 3
3.2.3 服务器停机
(1) 如果服务器运行在无持久化的内存模式下，那么重启之后的数据库将是空白的， 因此数据总是一致的。
(2) 如果服务器运行在RDB模式或AOF模式下， 那么在事务中途停机不会导致不一致，因为服务器可以根据RDB文件或AOF文件来回复数据，从而将数据库还原到一个一致的状态。
3.3 隔离性
事务的隔离性指的是，即使数据库中有多个事务并发地执行，各个事务之间也不会互相 影响，并且在并发状态下执行的事务和串行执行的事务产生的结果完全相同。
因为Redis使用单线程的方式来执行事务（以及事务队列中的命令），并且服务器保证， 在执行事务期间不会对事务进行中断，因此，Redis的事务总是以串行的方式运行的，并且 事务也总是具有隔离性的。
3.4 耐久性
事务的耐久性指的是，当一个事务执行完毕时，执行这个事务所得的结果巳经被保存到 永久性存储介质（比如硬盘）里面了， 即使服务器在事务执行完毕 之后停机， 执行事务所得的结果也不会丢失。Redis事务的耐久性由服务器所使用持久化模式决定的：
(1) 当服务器在无持久化的内存模式下运作时，事务不具有耐久性。因为一旦服务器停机，
服务器所有的数据都将丢失。
(2) 当服务器在ROB持久化模式下运作时，事务同样不具有耐久性。因为服务器只会在特定的保存条件下才会执行BGSAVE命令，并且异步执行的BGSAVE命令不能保证事务的数据第一时间被保存到硬盘上。
(3) 当服务器运行在AOF持久化模式下，并且appendfsync选项的值为always时，程序总会在执行命令之后调用同步(sync)函数，将命令数据真正地保存到硬盘里。
4.小结
(1) 事务提供了一种将多个命令打包，然后一次性、有序地执行的机制。
(2) 多个命令会被人队到事务队列中， 然后按先进先出(FIFO)的顺序执行。
(3) 事务在执行过程中不会被中断，当事务队列中的所有命令都被执行完毕之后，事务
才会结束。
(4) 带有WATCH命令的事务会将客户端和被监视的键在数据库的watched_keys字典关联，当键被修改时，程序会将所有监视被修改键的客户端的REDIS_DIRTY_CAS标识打开，服务只有在REDIS_DIRTY_CAS标识没有打开时，才会执行客户端提交的事务，否则服务器拒绝执行事务。
(5) Redis事务不支持回滚机制。
(6) Redis的事务总是具有ACID中的原子性、一致性和隔离性，当服务器运行在AOF持久化模式下，并且appendfsync选项的值为always时，事务也具有耐久性。
作者：HRADPX
转载链接： https://www.jianshu.com/p/479398a8e82c
来源：简书
kyrin