如何去玩 Redis 的事务？

事务

概念：可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞。一个队列中，一次性、顺序性、排他性的执行一系列命令

在 MySQL 中，事务有着四大特性，ACID，分别是原子性（Atomicity），一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。

注意：

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

在 Redis 中，也支持事务，可是 Redis 的事务没用隔离级别的概念，队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题所有的事务并没有直接被执行，只有在发起 EXEC 命令，才会执行。

不保证原子性：redis同一个事务中如果有一条命令执行失败（排除语法错误），其后的命令仍然会被执行，没有回滚（Redis 单条命令式可以保持原子性）

命令形式如下

> multi		# 开启事务
...			# 命令入队
> exec		# 执行事务

命令总结

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

怎么玩？

正常执行

127 .0.0.1:6379> multi  # 开启事务
OK
127 .0.0.1:6379> set k1 v1  # 命令入队
127 .0.0.1:6379> set k2 v2  # 命令入队
QUEUED
127 .0.0.1:6379> get k2
QUEUED
127 .0.0.1:6379> set k3 v3
QUEUED
127 .0.0.1:6379> exec  # 执行事务
1 ) OK
2 ) OK
3 ) "v2"
4 ) OK

放弃事务

192.168.200.132:6379> multi
OK
192.168.200.132:6379> set k4 v4
QUEUED
192.168.200.132:6379> discard		# 放弃事务
OK
192.168.200.132:6379> get k4
(nil)

异常

全体连坐

当发生代码有问题！ 命令有错！事务中所有的命令都不会被执行！也就是编译型的错误，因为 Redis 的命令都是在 EXEC 命令下才会执行，所以如果有语法错误，就都不执行。

192.168.200.132:6379> multi 
OK
192.168.200.132:6379> set k5 v5
QUEUED
192.168.200.132:6379> set k6 v6
QUEUED
192.168.200.132:6379> set k7		# 语法出错
(error) ERR wrong number of arguments for 'set' command
192.168.200.132:6379> set k8 v8
QUEUED
192.168.200.132:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.		# 提醒事务被抛弃
192.168.200.132:6379> get k5		# 获取设置的值为 null
(nil)
192.168.200.132:6379> get k7
(nil)

冤头债主

所有事务块中的指令没有语法错误，但是执行某一条指令出现错误，其他指令正常执行。也就是运行时异常。

192.168.200.132:6379> multi
OK
192.168.200.132:6379> set k5 v5
QUEUED
192.168.200.132:6379> set k6 v6
QUEUED
192.168.200.132:6379> incr k6 		# v6 并不是数字，无法进行加 1
QUEUED
192.168.200.132:6379> exec
1) OK
2) OK
3) (error) ERR value is not an integer or out of range
192.168.200.132:6379> get k5		#事务中 set k5 v5 命令还是照常运行
"v5"

悲观锁和乐观锁

**悲观锁：**顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会 block 直到它拿到锁。

类似一个人去公共厕所，怕有人偷窥，直接把公共厕所的大门给关了，把别人挡在完美。

**乐观锁：**很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。比如提交版本必须大于记录当前版本才能执行更新，乐观锁适用于多读的应用类型，这样可以提高吞吐量，

类似一个人去公共厕所的坑位，只把自己的小坑位门给锁住，而不直接关闭公共厕所的大门。

那么如何在 Redis 实现乐观锁？

使用 Redis 提供的 watch 命令监控即可

比如进程 1，事务开始前，watch 命令可以监控一个 key 值，然后在事务进行的过程中，如果有其他线程对这个 key 值进行了修改，假设进程 2，那么进程 1 的这个事务就会进行失效，不会执行。

正常情况：

线程 1

127 .0.0.1:6379> set money 100
OK
127 .0.0.1:6379> set out 0
OK
127 .0.0.1:6379> watch money # 监视 money 对象
OK
127 .0.0.1:6379> multi # 事务正常结束，数据期间没有发生变动，这个时候就正常执行成功！
OK
127 .0.0.1:6379> DECRBY money 20
QUEUED
127 .0.0.1:6379> INCRBY out 20
QUEUED
127 .0.0.1:6379> exec
1 ) (integer) 80
2 ) (integer) 20

如果出现了其他进程的修改

进程 2

127 .0.0.1:6379> incr money
OK

进程 1

127 .0.0.1:6379> watch money # 监视 money
OK
127 .0.0.1:6379> multi
OK
127 .0.0.1:6379> DECRBY money 10
QUEUED
127 .0.0.1:6379> INCRBY out 10
QUEUED
127 .0.0.1:6379> exec  # 执行之前，另外一个线程，修改了我们的值，这个时候，就会导致事务执行失
败！
(nil)

通过 WATCH命令在事务执行之前监控了多个 Keys，倘若在**WATCH 之后有任何 Key 的值发生了变化**，
EXEC 命令执行的事务都将被放弃，同时返回 Nullmulti-bulk 应答以通知调用者事务执行失败

一旦执行了 EXEC ，之前的监控锁都会被取消掉了。

其中，如果想要取消监控，可以使用 unwatch 命令取消，取消之后的修改就会生效。

jedis 如何玩？

导入 jedis 需要的 jar 包就不多说了吧

Commons-pool-x.x.jar
Jedis-x.x.x.jar

在 jedis 中，里面所有调用的函数，都是我们学习过的指令，看函数名就能知其意。所以 Redis 的指令学习很重要！

先获取连接对象

// 1、 new Jedis 对象即可
Jedis jedis = new Jedis("127.0.0.1", 6379 );

案例

// 开启事务
Transaction multi = jedis.multi();
String result = jsonObject.toJSONString();
// jedis.watch(result)
try {
    multi.set("key1","value1");
    multi.set("key2","value2");
	int i = 1 / 0 ; // 代码抛出异常事务，执行失败！
	multi.exec(); // 执行事务！
} catch (Exception e) {
	multi.discard(); // 放弃事务
	e.printStackTrace();
} finally {
	System.out.println(jedis.get("key1"));
	System.out.println(jedis.get("key2"));
	jedis.close(); // 关闭连接
}