六 事务
(一) 定义
定义：Redis 事务的本质是一组命令的集合
- 事务支持一次执行多个命令，一个事务中所有命令都会被序列化
- 在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中
即：redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令
首先
(二) 特点
(1)不保证原子性
可能受到关系型数据库的影响，大家会将事务一概而论的认为数据库中的事务都是原子性的，但其实，Redis 中的事务是非原子性的。
原子性：所有的操作要么全做完，要么就全不做，事务必须是一个最小的整体，即像化学组中的原子，是构成物质的最小单位。
- 数据库中的某个事务中要更新 t1表、t2表的某条记录，当事务提交，t1、t2两个表都被更新，只要其中一个表操作失败，事务就会回滚
非原子性：与原子性反之
- 数据库中的某个事务中要更新 t1表、t2表的某条记录，当事务提交，t1、t2两个表都被更新，若其中一个表操作失败，另一个表操作继续，事务不会回滚
(2) 不支持事务回滚
多数事务失败是由语法错误或者数据结构类型错误导致的，而语法的错误是在命令入队前就进行检测，而类型错误是在执行时检测的，Redis为提升性能而采用这种简单的事务
(3) 事务没有隔离级别的概念
批量操作在发送 EXEC 命令前被放入队列缓存，并不会被实际执行，也就不存在事务内的查询要看到事务里的更新，事务外查询不能看到
(三) 相关命令
(1) 开启事务
含义：开启事务，下一步就会将内容逐个放入队列中去，然后通过 exec 命令，原子化的执行
命令：multi
由于 multi 和 exec 需要搭配使用，所以在第二点一起演示示例
(2) 执行事务
含义：执行事务中的所有操作
命令：exec
A：正常开启且执行一个事务
首先先存一个 k1 和 k2，开启事务后，对这两个值进行修改，然后将这个事务执行，最后发现两个 OK ，然后用 get 查看一下值的变化
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> multi # 开启事务
OK
127.0.0.1:6379> set k1 v11 # 修改 k1
QUEUED
127.0.0.1:6379> set k2 v22 # 修改 k2
QUEUED
127.0.0.1:6379> exec # 执行事务
1) OK
2) OK
127.0.0.1:6379> get k1
"v11"
127.0.0.1:6379> get k2
"v22"
B：语法错误导致的事务失败
语法错误（编译器错误）导致的事务失败，会使得保持原值，例如下文事务中，修改 k1 没问题，但是修改 k2 的时候出现了语法错误，set 写成了 sett ，执行 exec 也会出错，最后发现 k1 和 k2 的值都没有变
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> multi # 开启事务
OK
127.0.0.1:6379> set k1 v11 # 修改正常
QUEUED
127.0.0.1:6379> sett k2 v22 # 修改有语法错误
(error) ERR unknown command `sett`, with args beginning with: `k2`, `v22`,
127.0.0.1:6379> exec # 执行事务
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get k1
"v1"
127.0.0.1:6379> get k2
"v2"
C：类型错误导致的事务失败
类型错误（运行时错误）导致的事务异常，例如下面 k2 被当做了一个 list 处理，这样在运行时就会报错，最后事务提交失败，但是并不会回滚，结果就是 k1 修改成功，而 k2 失败
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> multi # 开启事务
OK
127.0.0.1:6379> set k1 v11
QUEUED
127.0.0.1:6379> lpush k2 v22 # 类型错误
QUEUED
127.0.0.1:6379> exec # 执行事务
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
127.0.0.1:6379> get k1
"v11"
127.0.0.1:6379> get k2
"v2"
(3) 取消事务
这个没什么好说的，就是取消执行
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 k11
QUEUED
127.0.0.1:6379> set k2 k22
QUEUED
127.0.0.1:6379> discard
OK
(4) watch 监控
Redis的命令是原子性的，而事务是非原子性的，通过 watch 这个命令可以实现 Redis 具有回滚的一个效果
做法就是，在 multi 之前先用 watch 监控某些键值对，然后继续开启以及执行事务
- 如果 exec 执行事务时，这些被监控的键值对没发生改变，它会执行事务队列中的命令
- 如果 exec 执行事务时，被监控的键值对发生了变化，则将不会执行事务中的任何命令，然后取消事务中的操作
我们监控 k1，然后再事务开启之前修改了 k1，又想在事务中修改 k1 ，可以看到最后结果中，事务中的操作就都没有执行了
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> watch k1 # 监控 k1
OK
127.0.0.1:6379> set k1 v111111 # k1 被修改了
OK
127.0.0.1:6379> multi # 开启事务
OK
127.0.0.1:6379> set k1 v11
QUEUED
127.0.0.1:6379> set k2 v22
QUEUED
127.0.0.1:6379> exec # 执行事务
(nil)
127.0.0.1:6379> get k1
"v111111"
127.0.0.1:6379> get k2
"v2"
(5) unwatch 取消监控
取消后，就可以正常执行了
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> watch k1 # 监控
OK
127.0.0.1:6379> set k1 v111111
OK
127.0.0.1:6379> unwatch # 取消监控
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v11
QUEUED
127.0.0.1:6379> set k2 v22
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
127.0.0.1:6379> get k1
"v11"
127.0.0.1:6379> get k2
"v22"