redis事务

备注:测试版本 redis 4.0.9

一.redis事务概述

事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

一个事务从开始到执行会经历以下三个阶段：
开始事务。
命令入队。
执行事务。

二.redis事务相关命令

命令	概述
DISCARD	取消事务，放弃执行事务块内的所有命令
EXEC	执行所有事务块内的命令
MULTI	标记一个事务块的开始
UNWATCH	取消 WATCH 命令对所有 key 的监视
WATCH	监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。

2.1 测试multi、exec、discard命令

/* 测试事务提交 */
[root@10-31-1-123 ~]# redis-cli
127.0.0.1:6379> 
-- 开启事务
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incr user_id
QUEUED
127.0.0.1:6379> incr user_id
QUEUED
127.0.0.1:6379> incr user_id
QUEUED
-- 执行事务
127.0.0.1:6379> exec 
1) (integer) 1
2) (integer) 2
3) (integer) 3
127.0.0.1:6379> get user_id
"3"
127.0.0.1:6379> 

/* 测试取消事务 */
127.0.0.1:6379> del user_id
(integer) 1
127.0.0.1:6379> 
127.0.0.1:6379> get user_id
(nil)
-- 开启事务
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incr user_id
QUEUED
127.0.0.1:6379> incr user_id
QUEUED
127.0.0.1:6379> get user_id
QUEUED
-- 丢弃事务
127.0.0.1:6379> discard
OK
127.0.0.1:6379> get user_id
(nil)
127.0.0.1:6379> 

2.2 测试watch、unwatch命令

/* 测试 watch命令 */
127.0.0.1:6379> set key_test 1
OK
127.0.0.1:6379> watch key_test
OK
127.0.0.1:6379> set key_test 2
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set key_test 3
QUEUED
-- 已经被watch了的key是不能在事务里面提交的
127.0.0.1:6379> exec
(nil)
127.0.0.1:6379> get key_test
"2"

/* 测试unwatch命令 */
127.0.0.1:6379> del key_test
(integer) 1
127.0.0.1:6379> set key_test 1
OK

127.0.0.1:6379> watch key_test
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set key_test 3
QUEUED
127.0.0.1:6379> unwatch
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
127.0.0.1:6379> get key_test
"3"

三.redis事务的一些异常情况

redis的事务乍看之下，与关系型数据库例如MySQL有点类似。但是缺少关系型数据库的核心锁、MVCC，虽然有watch命令来模拟了类似锁的功能，但是如果watch的按个客户端不及时unwatch的话，影响其它的事务对key值的读取和更改。虽然watch命令可以设置锁定的时长，但是对于高并发的情况下，可能造成严重的阻塞，对系统的可用性造成了严重的影响。

3.1 事务中有错误

下例中可以看到，在一个事务中，如果有一个错误的命令，exec提交整个事务的时候，直接当成整个事务回滚了。
关系型数据库如果设计到错误的命令，都不会有这样的设置，依旧可以rollback或commit。
这点使用的时候要注意。

测试记录:

127.0.0.1:6379> multi
OK
127.0.0.1:6379> incr user_id
QUEUED
127.0.0.1:6379> error comman
(error) ERR unknown command 'error'
127.0.0.1:6379> 
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> 
127.0.0.1:6379> get user_id
(nil)
127.0.0.1:6379> 

这次测试的是事务中有一个错误的get key值的操作，虽然返回nil，但是不被事务认为是错误，只是一个空的key，事务依旧可以正常提交。

测试记录:

127.0.0.1:6379> multi
OK
127.0.0.1:6379> incr user_id
QUEUED
127.0.0.1:6379> get user_id
QUEUED
127.0.0.1:6379> get unknow_key
QUEUED
127.0.0.1:6379> exec
1) (integer) 1
2) "1"
3) (nil)
127.0.0.1:6379> get user_id
"1"
127.0.0.1:6379> get unknow_key
(nil)
127.0.0.1:6379> 

3.2 并发情况下的事务

关系型数据库有MVCC和锁，保证数据安全的情况下也保证了高并发，那么redis在并发的情况下会怎样呢?

session A	session B	描述
multi
incr user_id1
	multi
	incr user_id1
exec
get user_id1		返回为1
	exec
	get user_id1	返回为2
multi
incr user_id2
	multi
	incr user_id2
discard
	exec
get user_id2		返回1 证明被discard的并没有自增

从如上的并发测试中可以看到，对于incr这个命令来计数，并发情况下完全是OK的，不存在等待的情况，这个真给力。

session A	session B	描述
multi
incr user_id2
	get user_id2	返回nil
exec
	get user_id2	返回1

从如上的并发测试中可以看到，对于未exec的事务内容，其它客户端是看不到的，这个和关系型数据库是一致的，可以推断redis get key值，就是截止当前，所有提交事务的key的最新值，这种类似的关系型数据库的读提交级别。

参考

1.https://www.redis.net.cn/tutorial/3515.html