java做网站用什么软件/百度一下知道官网
Redis6
九）Redis6的事务操作
9.1）Redis的事务定义
Redis事务是一个单独的隔离操作：【事务操作是相互隔离的，其他操作不能插入到当前操作中】
-
事务中的所有命令都会序列化、按顺序地执行；
-
事务在执行的过程中，不会被其他客户端发送来的命令请求所打断；
-
主要作用就是串联多个命令防止别的命令插队
9.2）Redis的事务操作基本命令
9.2.1）事务操作的过程
-
从输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行；
-
直到输入Exec后，Redis会将之前的命令队列中的命令依次执行；
-
组队的过程中可以通过discard来放弃组队
事务操作的过程如下图：
9.2.2）事务操作的实例
展示 multi 和 exec
tx-root-redis:0>multi
"OK"
tx-root-redis:0>set k1 v1
"QUEUED"
tx-root-redis:0>set k2 v2
"QUEUED"
tx-root-redis:0>exec1) "OK"2) "OK"展示 multi 和 discard
tx-root-redis:0>set a1 s1
"QUEUED"
tx-root-redis:0>set a2 s2
"QUEUED"
tx-root-redis:0>discard
"OK"9.2.3）事务的错误处理
组队中某个命令出现了报告错误，执行时整个的所有队列都会被取消
案例展示：
tx-root-redis:0>multi
"OK"
tx-root-redis:0>set b1 v1
"QUEUED"
tx-root-redis:0>set b2 v2
"QUEUED"
tx-root-redis:0>set b3
"ERR wrong number of arguments for 'set' command"
tx-root-redis:0>exec
"EXECABORT Transaction discarded because of previous errors."如果执行阶段某个命令报出了错误，则只有报错的命令不会被执行，而其他的命令都会执行，不会回滚
案例展示：
tx-root-redis:0>multi
"OK"
tx-root-redis:0>set c1 v1
"QUEUED"
tx-root-redis:0>incr c1
"QUEUED"
tx-root-redis:0>set c2 v2
"QUEUED"
tx-root-redis:0>exec1) "OK"2) "ERR value is not an integer or out of range"3) "OK"9.2.4）事务冲突的问题
初始金额为：10000
三个请求：
一个请求想给金额减8000
一个请求想给金额减5000
一个请求想给金额减1000
请求过程如下图：
没有添加事务管理导致金额出现问题，事务管理是通过给事务添加锁的机制来实现的，锁分为悲观锁和乐观锁
9.2.5）事务冲突解决——悲观锁
悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁；
传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁；
结合案例，悲观锁的执行流程如下图：
每一次操作数据前先上锁，其他线程处于阻塞状态，不符合条件就不在执行
优点：可以解决上述出现的事务问题
缺点：效率低，只能单线程进行操作，不能多线程同时进行
9.2.6）事务冲突解决——乐观锁
乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制；
乐观锁适用于多读的应用类型，这样可以提高吞吐量；【抢票场景】
Redis就是利用这种check-and-set机制实现事务的；
结合案例，乐观锁的执行流程如下图：
每一次操作时，给要修改的字段添加版本号，所有线程都能收到该版本信息V1.0，第一个线程执行结束后，金额从 10000变成了2000，同时在更新金额时也要同步更新版本信息V1.0为V1.1，其他行程执行完成会判断当前该字段的版本信息【V1.1】是否跟数据库版本信息一致【V1.0】，不一致则不能执行该线程的修改操作
9.2.7）Redis中使用乐观锁
9.2.7.1）WATCH key [key ...]
在执行multi之前，先执行watch key1 [key2]，可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。
案例展示：使用两个客户端分别连接Redis
客户端1
127.0.0.1:11079> get balance
"100"
127.0.0.1:11079> watch balance
OK
127.0.0.1:11079> multi
OK
127.0.0.1:11079(TX)> incrby balance 10
QUEUED
127.0.0.1:11079(TX)> exec
1) (integer) 110
127.0.0.1:11079> get balance
"110"客户端2
127.0.0.1:11079> get balance
"100"
127.0.0.1:11079> watch balance
OK
127.0.0.1:11079> multi
OK
127.0.0.1:11079(TX)> incrby balance 20
QUEUED
127.0.0.1:11079(TX)> exec
(nil)
127.0.0.1:11079> get balance
"110"在客户端1对balance进行+10操作后，客户端2对balance进行+20的操作就不再生效了
9.2.7.2）unwatch
取消 WATCH 命令对所有 key 的监视
如果在执行 WATCH 命令之后，EXEC 命令或DISCARD 命令先被执行了的话，那么就不需要再执行UNWATCH了
官网文档：EXEC — Redis 命令参考
9.2.7）Redis事务三特性
-
单独的隔离操作 ：事务中的所有命令都会序列化、按顺序地执行，事务在执行的过程中，不会被其他客户端发送来的命令请求所打断 ；
-
没有隔离级别的概念： 队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行
-
不保证原子性 ：事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚