[TOC]
1 Redis事务简介
Redis可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入。
也就是说一次性、顺序性、排他性的执行一组命令,和传统的RDBMS的事务有点类似。
- 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
- 事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。
2 和事务相关的命令
2.1 multi
该命令开启一个事务，它总是返回 OK.
相当于session.begainTransaction().
2.2 exec
执行一个事务块内的所有命令。
相当于session.commit().
同时exec之前的监控所都被取消了。
2.3 discard
取消事务。
相当于session.rollback().
2.4 watch/unwatch
被 WATCH的键会被监视。如果有至少一个被监视的键在 EXEC 执行之前被修改了， 那么整个事务都会被取消， EXEC 返回nil-reply来表示事务已经失败。
相对的,UNWATCH命令用来取消对所有key的监视.
3 事务操作示例
3.1 正常结束的事务
127.0.0.1:6379> FLUSHALL
OK
127.0.0.1:6379> MULTI # 开启事务
OK # 该命令总是返回OK
127.0.0.1:6379> set k1 v1
QUEUED # 入队,等待exec
127.0.0.1:6379> get k1
QUEUED # get操作同样是入队
127.0.0.1:6379> set k2 v2
QUEUED # 入队
127.0.0.1:6379> EXEC
1) OK # set k1 v1 的返回值
2) "v1" # get k1 的返回值
3) OK # set k2 v2 的返回值
127.0.0.1:6379> keys *
1) "k1"
2) "k2"
127.0.0.1:6379>
3.2 正常取消的事务
127.0.0.1:6379> FLUSHALL
OK
127.0.0.1:6379> set k1 v1 # 先准备个历史数据
OK
127.0.0.1:6379> get k1
"v1"
127.0.0.1:6379> MULTI # 开启事务
OK
127.0.0.1:6379> set k1 v11111 # 修改k1的值为v11111
QUEUED
127.0.0.1:6379> get k1
QUEUED
127.0.0.1:6379> set k2 v222
QUEUED
127.0.0.1:6379> DISCARD # 取消事务
OK
127.0.0.1:6379> keys *
1) "k1" # set k2 v2 被回滚了
127.0.0.1:6379> get k1
"v1" # set k1 v11111 被回滚了
127.0.0.1:6379>
3.3 一个老鼠害一锅汤
127.0.0.1:6379> FLUSHALL
OK
127.0.0.1:6379> MULTI # 开启事务
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> a-error-cmd # 故意乱写一通
(error) ERR unknown command 'a-error-cmd'
127.0.0.1:6379> set k4 v4
QUEUED
127.0.0.1:6379> exec # 提交事务
# 上面手动制造的a-error-cmd导致的
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> keys *
(empty list or set) # 一条也没有生效
127.0.0.1:6379>
3.4 对的执行错的回滚
127.0.0.1:6379> FLUSHALL
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> get k1
QUEUED
127.0.0.1:6379> INCRBY k1 10
QUEUED
127.0.0.1:6379> get k1
QUEUED
127.0.0.1:6379> exec
1) OK
2) "v1"
3) (error) ERR value is not an integer or out of range
4) "v1"
127.0.0.1:6379>
和上一个示例中的错误不同的是：
- 此处的incrby相当于Java中的运行时异常,只有在真正运行时才能发现的错误(只回滚错误的命令)
- 而上一个示例中伪造的命令
a-error-cmd相当于Java中在静态编译时就可以确定的错误(全部回滚)
3.5 watch/unwatch示例
此处的个人信用卡的示例来自尚硅谷教学视频：
- 正常的
watch示例—两笔金额的变动在同一个事务内发生
127.0.0.1:6379> set balance 100
OK
127.0.0.1:6379> set debt 0
OK
127.0.0.1:6379> WATCH balance
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> DECR balance
QUEUED
127.0.0.1:6379> INCR debt
QUEUED
127.0.0.1:6379> exec # 监控锁也被取消了
1) (integer) 99
2) (integer) 1
127.0.0.1:6379>
- 被中断了的watch
watch
3.6 总结
Watch指令，类似乐观锁，事务提交时，如果Key的值已被别的客户端改变(比如某个list已被别的客户端push/pop过了)整个事务队列都不会被执行.
-
通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化，
EXEC命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败.
4 Redis事务的总结
-
事务相关的命令
- multi开启事务
- 开启事务后,提交的命令不会被立即执行,而是入队
- exec提交事务,执行命令
- discard回滚放弃事务
-
事务的特性
- 事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断
- 队列中的命令没有提交之前都不会实际的被执行
- redis同一个事务中如果有一条命令执行失败，正确的命令仍然会被执行，不会回滚(不保证
原子性)
