三、Redis事务

1.Redis事务的定义

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

1.1.Redis事务的特点

• **单独隔离操作：**事务中所有命令都会序列化按顺序的执行。事务在执行过程中不会被其他客户端发送来的命令请求打断。
• **没有隔离级别的概念：**事务在提交前，任何指令都不会被执行
• **不保证原子性：**食物中如果有一条命令执行失败，其他命令依旧会执行，不会整体回滚。

2.事务的命令（Multi / Discard / Exec ）

2.1.Multi

Multi指令标识一个事务的开始，后续指令进入事务队列等待被执行。
在开始事务组队后输入的某个指令出现报错，则整个事务队列都会被作废

正确输入时：
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 1
QUEUED
127.0.0.1:6379(TX)> set k2 22
QUEUED
127.0.0.1:6379(TX)> set k3 333
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) OK
3) OK

报错时：

127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 abc
QUEUED
127.0.0.1:6379(TX)> set k2
(error) ERR wrong number of arguments for 'set' command

2.2.Discard

在命令组队阶段可以执行 discard 命令,放弃在组队的事务,对于已经存在缓存队列中的命令不会执行全部作废,关闭当前事务

127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 11
QUEUED
127.0.0.1:6379(TX)> set k2 22
QUEUED
127.0.0.1:6379(TX)> discard
OK
127.0.0.1:6379>

2.3.Exec

执行事务队列中的命令
只有出现错误的命令不执行，其他任务都执行

127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> set k3 v3
QUEUED
127.0.0.1:6379(TX)> incr k1
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) OK
3) OK
4) (error) ERR value is not an integer or out of range

3.乐观锁（WATCH）和悲观锁（UNWATCH）

3.1.乐观锁（WATCH）

乐观锁(Optimistic Lock),
顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。

在执行multi命令之前,可以先执行WATCH key (监视一个或者多个key),如果在事务执行之前watch监视的一个或者多个key被其他命令改动,那么事务将会被打断,有点类似我们上面介绍的乐观锁

3.2.悲观锁（UNWATCH）

悲观锁(Pessimistic Lock),
顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
但是在效率方面，处理加锁的机制会产生额外的开销，还有增加产生死锁的机会。另外还会降低并行性，如果已经锁定了一个线程A，其他线程就必须等待该线程A处理完才可以处理。

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