机制"/>

Redis——事务 锁机制

文章目录：

1.Redis中事务的定义

1.1 案例一：事务中组队成功、提交成功

1.2 案例二：事务中组队阶段报错、提交失败

1.3 案例三：事务中组队成功，提交有成功有失败情况

2.Redis中的锁机制

2.1 悲观锁

2.2 乐观锁

2.3 watch、unwatch命令

1.Redis中事务的定义

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

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

Redis事务的三特性：

• 单独的隔离操作 ：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
• 没有隔离级别的概念 ：队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行。
• 不保证原子性 ：事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。

Redis事务的相关命令主要是以下这三个：

Multi、Exec、discard

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

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

下面，我们来看一个简单的事务案例。

我将redis的安装包存到了/opt目录下， 然后 tar -zxvf 进行解压，之后make、make install进行安装就可以了，这个步骤我就不再多说了。

上面的截图是在linux环境下，启动redis的步骤，安装之后redis的启动命令都在 /usr/local/bin 目录下，/etc/redis.conf 是redis的配置文件。

启动的时候，记得把防火墙关了。

下面使用 multi、exec、discard 命令进行事务操作。

1.1 案例一：事务中组队成功、提交成功

上面的案例，从 multi 开启事务，之后向redis中存入两个key，之后 exec 正常执行事务。discard 可以放弃事务的执行。

通过 keys * 命令可以看到目前redis中只有exec命令执行后的key，而discard放弃执行事务的key（k1、k2）是不存在的。

1.2 案例二：事务中组队阶段报错、提交失败

这里multi开启事务，在第三个 set 的时候，出现了错误语法，然后再执行 exec，可以看到事务全部不执行。

也就是说，只有 multi 的组队阶段出现一个错误，那么整个事务中所有的命令全部不会执行。

1.3 案例三：事务中组队成功，提交有成功有失败情况

这里multi开启事务，然后组队阶段无任何语法错误，但是我们 exec 的时候，可以看到事务命令依次执行，在第二个命令的时候出错了。

这是因为k1这个键，是String类型的，肯定不能使用 incr 进行自增1操作，所以这条命令报错，但是其他命令正常执行。

也就是说，如果 multi 组队阶段没有出现错误，而在 exec 执行阶段某个命令报出了错误，则只有报错的命令不会被执行，而其他的命令都会执行，不会回滚。

2.Redis中的锁机制

2.1 悲观锁

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

2.2 乐观锁

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

2.3 watch、unwatch命令

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

unwatch 命令用来取消 WATCH 命令对所有 key 的监视。

如果在执行 WATCH 命令之后，EXEC 命令或 DISCARD 命令先被执行了的话，那么就不需要再执行 UNWATCH 了。v

上面的截图，开启了两个redis客户端，这两个redis客户端分别对 balance 这个键进行watch监控。

然后分别在这两个客户端中，multi 开启事务，之后在第一个客户端中 incrby 对 balance 进行增加50的操作，然后exec执行事务，可以看到此时第一个客户端中的balance的值被修改为了150。然后我们来到第二个客户端中，在事务中使用 incrby 对 balance 进行增加20的操作，然后exec执行事务，可以看到返回了nil，也就是说事务无法执行。

这是因为在第二个客户端想对balance进行增加操作时（版本号为1.0），由于balance此时已经被第一个客户端监控了，在第一个客户端对balance执行增加操作后exec执行事务，此时balance的值变成了150（版本号为1.1），当第二个客户端再次exec执行事务时，会比较版本号（1.0 ≠ 1.1），所以这里的事务不会执行。