三、Redis 事务和锁机制

Redis 事务和锁机制

1. 事务简介

redis事务就是一个命令执行的队列，将一系列预定义命令包装成一个整体（一个队列）。当执行时，一次性按照添加顺序依次执行，中间不会被打断或者干扰。

Redis事务三特性

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

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

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

2. 事务基本指令

• multi：设定事务的开启位置，此指令执行后，后续的所有指令均加入到事务中
• exec：设定事务的结束位置，同时执行事务，与multi成对使用

redis事务执行流程

1. multi（开启事务）
2. 命令入队
3. exec （执行事务）
   discard （放弃事务）

3. 事务的执行案例

3.1 正常执行事务

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)> get k2
QUEUED
127.0.0.1:6379(TX)> set k3 v3
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) OK
3) "v2"
4) OK
127.0.0.1:6379> 

3.2 放弃事务

127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> set k4 v4
QUEUED
127.0.0.1:6379(TX)> discard
OK
127.0.0.1:6379> keys *
1) "k3"
2) "k2"
3) "k1"
127.0.0.1:6379> 

3.3 编译时异常（代码有问题，命令有问题）

事务中所有命令都不会被执行。

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)> getset k3
(error) ERR wrong number of arguments for 'getset' command
127.0.0.1:6379(TX)> set k4 v4
QUEUED
127.0.0.1:6379(TX)> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get k1
(nil)
127.0.0.1:6379> 

3.4 运行时异常（逻辑错误，错误使用命令）

事务中正确的部分会被执行，错误的部分则不会被执行。

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> incr k1
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> get k2
QUEUED
127.0.0.1:6379(TX)> exec
1) (error) ERR value is not an integer or out of range #虽然第一条命令报错，但是依旧正常执行
2) OK
3) "v2"
127.0.0.1:6379> get k2
"v2"
127.0.0.1:6379> 

4. Redis 锁机制

悲观锁

顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

比较适合写入操作比较频繁的场景，如果出现大量的读取操作，每次读取的时候都会进行加锁，这样会增加大量的锁的开销，降低了系统的吞吐量。

乐观锁

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

比较适合读取操作比较频繁的场景，如果出现大量的写入操作，数据发生冲突的可能性就会增大，为了保证数据的一致性，应用层需要不断的重新获取数据，这样会增加大量的查询操作，降低了系统的吞吐量。

watch和unwatch

Redis中可以使用watch和unwatch实现锁机制。

在执行multi之前，先执行watch key1 [key2]，可以监视一个 (或多个) key ，如果在事务执行之前这个 (或这些) key 被其他命令所改动，那么事务将被打断。

unwatch可以取消watch命令对所有key的监视。如果在执行watch命令之后，exec命令或discard命令先被执行了的话，那么就不需要再执行 unwatch了。

乐观锁案例

下面是一个多线程修改值的案例，我们使用watch来实现乐观锁。

money和out都是一个String类型的值，表示已有的钱和花出去的钱，初始时分别设置为100和0.

首先开启一个客户端，开启一个事务，将money减去10，接着将out加上10，但是不提交事务。

这个时候，再次开启一个客户端模拟第二个线程，第二个线程将money直接设置成1000。

然后我们再返回第一个客户端使用exec提交事务，这个时候会发现执行的结果是(nil)，没有执行成功。实现了一个乐观锁的效果。

执行失败之后可以先使用unwatch放弃监视，然后接着进行后续的操作。

# 如果事务执行失败，先解锁
127.0.0.1:6379> unwatch
OK
# 获取最新值，再次监视 
127.0.0.1:6379> watch money
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> decrby money 1
QUEUED
127.0.0.1:6379(TX)> incrby money 1
QUEUED
127.0.0.1:6379(TX)> exec 
# 对比监视值是否发送变化，如果没有变化可以执行，变化则执行失败
1) (integer) 999
2) (integer) 1000
127.0.0.1:6379>