文章目录
官方文档
一、为什么要用事务
Redis的单个命令是原子性的（比如 get 、set、mget、mset），要么成功要么失败，不存在并发干扰的问题。
如果涉及到多个命令的时候，需要把多个命令作为一个不可分割的处理序列，就必须要依赖Redis的功能特性来实现了。
Redis提供了事务的功能，可以把一组命令一起执行。Redis的事务有3个特点：
- 按进入队列的顺序执行。
- 不会受到其他客户端的请求的影响。
- 事务不能嵌套，多个multi命令效果一样。
二、事务的用法
Redis的事务涉及到四个命令：multi（开启事务），exec（执行事务），discard（取消事务），watch（监视）。
1、使用实例
tom和mic各有1000元，tom向mic转账100元。
127.0.0.1:6379> set tom 1000
OK
127.0.0.1:6379> set mic 1000
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby tom 100
QUEUED
127.0.0.1:6379> incrby mic 100
QUEUED
127.0.0.1:6379> exec
1) (integer) 900
2) (integer) 1100
127.0.0.1:6379> get tom
"900"
127.0.0.1:6379> get mic
"1100"
通过multi的命令开启事务，multi执行后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即执行，而是被放到一个队列中。当exec命令被调用时，所有队列中的命令才会被执行。
如果没有执行exec命令，所有的命令都不会被执行。
2、事务取消
如果中途不想执行事务了，怎么办？可以使用discard命令清空事务队列，放弃执行。
127.0.0.1:6379> set tom 1000
OK
127.0.0.1:6379> set mic 1000
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby tom 100
QUEUED
127.0.0.1:6379> discard
OK
127.0.0.1:6379> get tom
"1000"
3、watch命令
为了防止事务过程中某个key的值被其他客户端请求修改，带来非预期的结果，在Redis中海提供了一个watch命令。
也就是说，多个客户端更新变量的时候，会跟原值做比较，只有它没有被其他线程修改的情况下，才更新成新的值。它可以为Redis事务提供CAS乐观锁的行为（Compare and Swap）。
我们可以用watch监视一个或多个key，如果开启事务之后，至少有一个被监视key键在exec执行之前被修改了，那么整个事务都会被取消（key提前过期除外）。可以用unwatch取消。
| client-1 | client-2 |
|---|---|
| 127.0.0.1:6379> set balance 1000 OK 127.0.0.1:6379> watch balance OK 127.0.0.1:6379> multi OK 127.0.0.1:6379> incrby balance 100 QUEUED | |
| \ | 127.0.0.1:6379> decrby balance 100 (integer) 900 |
| 127.0.0.1:6379> exec (nil) 127.0.0.1:6379> get balance “900” |
三、事务异常
我们都知道，mysql事务执行时发生异常之后，会自动回滚。
Redis事务在执行的过程中发生了异常，会回滚吗？
事务执行遇到的问题一般分为两种，一种是在执行exec之前发生错误，一种是在执行exec之后发生错误。
1、在执行exec之前发生错误
比如：入队的命令存在语法错误，包括参数数量、参数名等等（编译器错误）。
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set zhangsan 123
QUEUED
127.0.0.1:6379> set lisi 321
QUEUED
127.0.0.1:6379> hset wangwu 333
(error) ERR wrong number of arguments for 'hset' command
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
我们会发现，hset我们的语法有问题，事务会被拒绝执行，也就是队列中所有的命令都不会得到执行。
2、在执行exec之后发生错误
比如：对String使用了hash命令，参数个数正确，但是数据类型错误，这是一种运行时错误。
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set a 1
QUEUED
127.0.0.1:6379> hset a aa bb
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 a
"1"
我们发现，第一条命令是执行成功的，也就是在发生异常的情况下，之后错误的命令没有被执行，正确的命令还是执行成功，并没有被回滚。
这显然不符合我们对原子性的定义。也就是没办法用Redis的这种事务机制来实现原子性，保证数据一致。
3、为什么不回滚
官方的解释：
- Redis命令只会因为错误的语法而失败，也就是说，从实用性的角度来讲，失败的命令是由代码错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中（程序员的锅）。
- 因为不需要对回滚进行支持，所以Redis的内部可以保持简单快速。需要知道的是：回滚不能解决代码的问题（程序员的锅必须程序员来背，不应当交由Redis开发者来规避）。
