Redis 之 事务讲解

事务介绍

任何数据库都要有一套自己的事务控制机制，redis 事务是一次可以执行多个命令，它的本质是一组命令的集合。一个事务中所有的命令都会被序列化，在事务执行的过程中会按照顺序执行队列中的命令。其它客户端提交的命令请求会等到事务执行完毕再执行。

总的来说：redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。

与其他数据库相比：

1. redis事务是分为三个阶段：开始事务、命令入队、执行事务。
2. redis事务不具有隔离级别的概念：redis 在发送 exec 命令之前，命令操作只是被放入到队列缓存当中，并不会被实际执行，因此也就不能类似关系型数据中，在事务内查询已经变更的操作，事务外的客户端更不能查询到事务内的数据。
3. redis 事务是不保证原子性的：redis 事务只保证在命令格式只有在都正确的情况下才会都执行，要不就都不执行命令。但是事务的整体是不保证原子性的，且没有回滚，当事务中任意一个命令执行失败，其余的命令依然会执行。

事务命令入队过程

事务命令解释

multi 命令

用于开启一个事务，它总是返回OK。MULTI执行之后,客户端可以继续向服务器发送任意多条命令， 这些命令不会立即被执行，而是被放到一个队列中，当 EXEC命令被调用时， 所有队列中的命令才会被执行。

exec 命令

执行开启 multi 命令后输入的操作命令。

watch 命令

可以为 Redis 事务提供 check-and-set （CAS）行为。被 watch 的键会被监视，并会发觉这些键是否被改动过了。 如果有至少一个被监视的键在 exec 执行之前被修改了， 那么整个事务都会被取消， exec 返回nil-reply来表示事务已经失败。

unwatch 命令

取消 watch 命令对所有 key 的监视。
如果执行了 exec 提交命令，就不需要再执行 unwatch 命令了。

事务WATCH命令监控

Redis Watch 命令用于监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。

开启第一个客户端
127.0.0.1:6379> watch name
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name zhangsan
QUEUED
127.0.0.1:6379> get name
QUEUED
127.0.0.1:6379>


开启第二个客户端
127.0.0.1:6379> watch name
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name lisi
QUEUED
127.0.0.1:6379> get name
QUEUED
127.0.0.1:6379>


客户端一：执行事务
127.0.0.1:6379> exec
1) OK
2) "zhangsan"
127.0.0.1:6379>

客户端二：执行事务
127.0.0.1:6379> exec
(nil)
127.0.0.1:6379>

事务ACID

一、持久性

事务的耐久性指的是，当一个事务执行完毕时，执行这个事务所得的结果巳经被保存到 永久性存储介质（比如硬盘）里面了， 即使服务器在事务执行完毕 之后停机， 执行事务所得的结果也不会丢失。Redis 事务的耐久性由服务器所使用持久化模式决定的：

1. 当服务器在无持久化的内存模式下运作时，事务不具有耐久性。因为一旦服务器停机，服务器所有的数据都将丢失。

2. 当服务器在 ROB 持久化模式下运作时，事务同样不具有耐久性。因为服务器只会在特定的保存条件下才会执行 BGSAVE 命令，并且异步执行的 BGSAVE 命令不能保证事务的数据第一时间被保存到硬盘上。

3. 当服务器运行在 AOF 持久化模式下，并且 appendfsync 选项的值为 always 时，程序总会在执行命令之后调用同步(sync)函数，将命令数据真正地保存到硬盘里。

二、隔离性

事务的隔离性指的是，即使数据库中有多个事务并发地执行，各个事务之间也不会互相 影响，并且在并发状态下执行的事务和串行执行的事务产生的结果完全相同。 因为 Redis 使用单线程的方式来执行事务（以及事务队列中的命令），并且服务器保证， 在执行事务期间不会对事务进行中断，因此，Redis 的事务总是以串行的方式运行的，并且 事务也总是具有隔离性的。

三、一致性

事务的一致性是指，如果数据库执行前是一致的，那么在事务执行后，无论事务是否执行成功，数据库也应该是一致的。

1.入队错误：

如果一个事务在入队命令的过程中，出现了命令不存在，或者命令的格式不正确等情况， 那么Redis将拒绝执行这个事务。因为服务器会拒绝执行入队过程中出现错误的事务， 所以Redis事务的一致性不会被带有入队错误的事务影响。

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set msg HelloWord
QUEUED
127.0.0.1:6379> get
(error) ERR wrong number of arguments for 'get' command
127.0.0.1:6379> get msg
QUEUED
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get msg
(nil)
127.0.0.1:6379> 

注意：Redis 2.6.5 以前的入队错误处理：Redis 会忽略错误的命令，而正确的命令如上面的 SET 和 GET 仍然会被执行。

2.执行错误：

执行错误通常都是一些不能在入队时被服务器发现的错误， 这些错误只会在命令实际执行时被触发。即使在事务的执行过程中发生了错误， 服务器也不会中断事务的执行， 它会继续执行事务中余下的其他命令，并且已执行的命令（包括执行命令所产生的结果）不会被出错的命令影响。 因为在事务执行的过程中，出错的命令会被服务器识别出来， 并进行相应的错误处理， 所以这些出错命令不会对数据库做任何修改，也不会对事务的一致性产生任何影响。

127.0.0.1:6379> set msg HelloWord
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> sadd fruit apple banana cherry
QUEUED
127.0.0.1:6379> rpush msg bye redis
QUEUED
127.0.0.1:6379> sadd alphabet a b c
QUEUED
127.0.0.1:6379> exec
1) (integer) 3
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
3) (integer) 3
127.0.0.1:6379> 

四、原子性

事务具有原子性指的是， 数据库将事务中的多个操作当作一个整体来执行，服务器要么就执行事务中的所有操作， 要么就一个操作也不执行。 对于 Redis 的事务功能来说，事务队列中的命令要么就全部都执行，要么就一个都不执行，因此， Redis 的事务是具有原子性的。 下面是一个执行失败的事务，这个事务因为命令入队出错而被服务器拒绝执行：

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set msg HelloWord
QUEUED
127.0.0.1:6379> get
(error) ERR wrong number of arguments for 'get' command
127.0.0.1:6379> get msg
QUEUED
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get msg
(nil)
127.0.0.1:6379> 

Redis的事务和传统的关系型数据库事务的最大区别在于，Redis不支持事务回滚机制(rollback)， 即使事务队列中的某个命令在执行期间出现了错误，整个事务也会继续执行下去，直到将事务队列中的所有命令都执行完毕为止。 下面展示了即使RPUSH命令在执行期间出现了错误，事务的后续命令也会继续执行下去，并且之前执行的命令也不会有任何影响：

127.0.0.1:6379> set msg HelloWord
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> sadd fruit apple banana cherry
QUEUED
127.0.0.1:6379> rpush msg bye redis
QUEUED
127.0.0.1:6379> sadd alphabet a b c
QUEUED
127.0.0.1:6379> exec
1) (integer) 3
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
3) (integer) 3
127.0.0.1:6379> 

Redis 为什么不支持回滚：不支持事务回滚是因为这种复杂的功能和Redis追求简单高效的设计主旨不相符，并且 Redis 事务的执行时错误通常都是编程错误产生的， 这种错误通常只会出现在开发环境中， 而很少会在实际的生产环境中出现。