Redis学习笔记（3）-事务和锁机制

ps:这是我的个人笔记地址： TinkerBell学习笔记

Redis事务的基本概念

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

• Redis 事务的主要作用就是串联多个命令防止别的命令插队。

• Redis的单条语句保持原子性，但是事务不保持原子性

• Redis的事务没有隔离级别的概念

• Redis事务中的所有命令，只有在发起执行命令Exec后才会执行

Redis 事务三特性

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

• 没有隔离级别的概念 ：队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行。

• 不保证原子性 ：事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚 。

执行流程：

• 1.开起事务（Multi）
• 2.命令入队（…）
• 3.执行事务（exec）

127.0.0.1:6379> MULTI #开启事务
OK
127.0.0.1:6379(TX)> set key1 v1
QUEUED
127.0.0.1:6379(TX)> set key2 v2
QUEUED
127.0.0.1:6379(TX)> exec #执行事务
1) OK
2) OK

放弃事务DISCARD(相当于回滚事务)

127.0.0.1:6379> MULTI  #开启事务
OK
127.0.0.1:6379(TX)> set key3 v3
QUEUED
127.0.0.1:6379(TX)> DISCARD #放弃事务
OK

事务执行出现异常

• 编译时异常（如果事务队列中一个命令编译错误，就都不执行）

127.0.0.1:6379> MULTI  #开启事务
OK
127.0.0.1:6379(TX)> set key1 v1
QUEUED
127.0.0.1:6379(TX)> setsjcs  #错误的命令
(error) ERR unknown command 'setsjcs', with args beginning with: 
127.0.0.1:6379(TX)> exec 
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get key1
(nil)  #所有的命令都不执行，之前的key1也没有设置进去

• 运行时异常，如果事务队列中某条命令运行时异常，其他的命令是可以正常执行的

127.0.0.1:6379> MULTI #开启事务
OK
127.0.0.1:6379(TX)> set key1 "v1"
QUEUED
127.0.0.1:6379(TX)> INCR key1 #对字符串进行加一操作
QUEUED
127.0.0.1:6379(TX)> set key2 v2
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) (error) ERR value is not an integer or out of range #运行时的异常
3) OK
127.0.0.1:6379> get key1
"v1"
127.0.0.1:6379> get key2
"v2"

解读：

• （Multi）把开启事务看成一个小管道，

• 例如把5条命令装进这个管道（命令入队），在命令入队时，如果有一条命令出错，则这个“管道”失效，即不会被执行，反之正确的情况下，命令入列被序列化等待被执行exec

• 当执行事务（exec）时，“盒子”看成一个最小单元，许许多多的盒子串行执行，这也是Redis没有隔离级别的意思，都是串行化执行，在串行化执行中：如果任务出错，并不会回滚：因为Redis的事务是通过Multi和Discard来实现回滚

Multi、Exec、Discard

上面已经演示过了，简单讲解一下各命令的含义

Multi

Exec

Discard

从输入 Multi 命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入 Exec 后，Redis 会将之前的命令队列中的命令依次执行。

组队的过程中可以通过 Discard 来放弃组队。


Redis的事务就是：先使用multi进行命令的添加（组队过程），组队完毕后，使用exec进行执行，这个执行过程不能被其他命令打断（相当于事务执行的过程），如果要中止，就使用discard命令（类似于回滚操作）。

锁

悲观锁

悲观锁（Pessimistic Lock），即每次去拿数据的时候都认为有其他线程会修改，所以每次在拿数据的时候都会上锁，这样其他线程想要拿到这个数据就会被 block 直到释放锁后，成功拿到锁。（效率低，操作之前先上锁）

乐观锁

乐观锁（Optimistic Lock），即每次去拿数据的时候都认为其他线程不会修改，所以不会上锁，但是在更新的时候会判断，在此期间有没有其他线程去更新这个数据，可以使用版本号控制等机制。

乐观锁适用于多读的应用类型，这样可以提高吞吐量。

Redis 就是利用这种 check-and-set 机制实现事务的。

Watch、unwatch

之前讲了，Redis锁是基于乐观锁的，就是任何时候都不上锁，只在更新数据的时候检查这个数据是否被修改过，如果修改过就不更新，没被修改就更新

所以这里引入watch（Redis监控）

在执行 multi 之前，先执行 watch key1 [key…]，可以监视一个（或多个 ）key 。如果在事务执行之前，这个 key 被其他命令所改动，那么事务将被打断。（类似于上锁，一旦发现watch的这个key被修改了，那么自己的exec操作就会中断）

取消 WATCH 命令对所有 key 的监视：如果在执行 WATCH 命令之后，EXEC 命令或 DISCARD 命令先被执行，那么就不需要再执行 UNWATCH 。

正常执行

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 #监视钱数的变化
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> DECRBY money 20 #总钱数减少20
QUEUED
127.0.0.1:6379(TX)> INCRBY out 20 #拿出的钱数增加20
QUEUED
127.0.0.1:6379(TX)> exec
1) (integer) 80
2) (integer) 20

当事务执行的过程中有其他的线程来修改了数据，那么就会撤销此次事务操作

127.0.0.1:6379> watch money #监视总钱数
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> decrby money 20 #总钱数减20
QUEUED
127.0.0.1:6379(TX)> incrby out 20 #拿出的钱加20
QUEUED
127.0.0.1:6379(TX)> exec   #事务执行之前有人对数据进行了修改，因此事务执行失败
(nil)