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同一个事务中如果有一条命令执行失败，正确的命令仍然会被执行，不会回滚(不保证原子性)

redis-06-事务