深入学习 Redis - 事务、实现原理、指令使用及场景

目录

一、Redis 事务 vs MySQL事务

二、Redis 事务的执行原理

2.1、执行原理

2.2、Redis 事务设计这么简单，为什么不涉及成 MySQL 那样强大呢？

三、Redis 事务的使用

3.1、使用场景

3.2、具体演示

开启/执行/放弃事务

watch 监控

watch 实现原理

小结

---

一、Redis 事务 vs MySQL事务

---

我们熟知的 MySQL，你还记得她的事务特性么？

1. 原子性：将多个操作打包成一个整体，要么全都执行成功，要么一个都不执行，一旦执行出错，立刻回滚如初.
2. 一致性：事务执行前后，通过约束和回滚机制，保证数据合理. 例如我去银行给 张三 转账 1 元钱，那么我的卡里就会减少 1 元，张三的卡里就会增加 1 元，不能增加 100 元。
3. 持久性：事务做出的修改都会存储到硬盘上，不会随着服务器重启而丢失.
4. 隔离性：事务并发执行，涉及到的一些问题.

Redis 的事务和 MySQL 相比，就像一个“弟弟”~

1. 原子性：Redis 的事务到底有没有在原子性，存在争议！因为从 Redis 的角度理解就是“把多个操作打包到一起，要么全都执行，要么全都不执行”，也就是说，这里如果中途执行失败，那就失败吧，不会有像 MySQL 那样回滚的操作（也因此，网上有人一部分人说 redis 事务有原子性，一部分说没有原子性，都对，但是要看从那个角度出发了~）.
2. 不具备一致性：redis 没有约束和回滚，事务执行一旦出错，就可能导致不一致的情况.
3. 不具备持久性：Redis 本身就是内存数据库，数据是存储在内存中的. 虽然 Redis 也有持久化机制，但是这里的持久化机制和事务没有什么直接关系.
4. 不具备隔离性：Redis 是一个单线程模型的服务器程序，所有的请求 / 事务，都是 “串行” 执行的.

二、Redis 事务的执行原理

---

2.1、执行原理

Redis 事务的主要意义就是为了 “打包” ，避免其他客户端的命令，插队到其中，那他具体是通过什么实现的呢？Redis 实现事务，是引入了队列（每一个客户端都有），开启事务的时候，客户端输入的命令，就会发给服务器，然后进入都这个队列中，此时并不会立即执行，当收到 “执行事务” 命令的时候，就会把队列中的这些任务按照顺序依次执行（这里是由 Redis 主线程执行的，他会把事务中的操作执行完，再去执行其他客户端）.

举个例子，这就像是你去做核酸检测，但是核酸检测是早上 7 点开始，但是你 6 点就来了，还发现已经有一些人在这里排成长队，所以这个时候你只能在去后面排队，不能插队，等到核酸检测开始，并且前面的人都检测完了，才轮到你~

2.2、Redis 事务设计这么简单，为什么不涉及成 MySQL 那样强大呢？

MySQL 的事务之所以能设计的这么强大（原子性、一致性....），背后是付出了很多代价的~

1. 空间上，要花费跟多的空间来存储更多的数据，例如 MySQL 事务执行中途出错，引发的回滚机制，这种回滚机制也是需要花费空间去记录每条执行的指令是什么，才能进行回滚的.
2. 时间上，也要有更大的执行开销，比如 MySQL 事务的持久化机制，是存储在硬盘上的，操作缓慢；再例如 MySQL 中事务遇到冲突是进行加锁，加锁也是需要开销的，涉及到用户态到内核态的转化，而且加锁就有可能产生锁竞争，一竞争就会加锁排队，一排队就不知道什么时候释放锁了~

也正因如此，Redis 才有了上场的机会。

三、Redis 事务的使用

---

3.1、使用场景

如果需要把多个操作打包进行，使用事务就是比较合适的~

比如说以前春运，咱们在网上抢火车票的场景、秒杀...

这里以抢火车票的场景为例：

假设现在有大量的用户都在同一时间段开始抢票，也就是说有多个 Redis 客户端执行执行抢票操作，如下：

获取仓库中剩余的票数;
if(剩余的票数 > 0) {
    下单成功;
    商品数量--;
}

这里如果不加任何限制，就有可能引发 “线程安全” 问题~  以前咱们解决线程安全问题，都是通过加锁排队来避免 “插队” 的，而 redis 这里不加锁，也能解决上述问题，直接使用事务即可，如下：

开启事务
get count
if count > 0
    decr count
执行事务

Ps：Redis 原生的命令中是没有上述这种判断的，但是 Redis 支持 lua 脚本，通过 lua 脚本就可以实现上述的 条件判定，并且也和事务一样是打包批量执行的.

确实，redis 的事务使用场景没有 mysql 事务那么多，并且 redis 如果是按照集群模式部署，是不支持事务的.

3.2、具体演示

redis 的事务是通过以下命令进行控制的

multi        开启事务（读作 “猫体”）
exec         执行事务
discard      放弃当前事务
watch        监控某个 key 是否在事务执行之前发生变化（必须搭配事务使用）
unwatch      放弃监控

开启/执行/放弃事务

开启事务，执行以下命令:

此时开启另一个客户端，查看这几个 key ，会发现这几个 key 并没有被赋值（说明此时还没有执行事务).，如下

如果放弃事务，就相当于什么也没有发生，如下

如果使用 exec，就会按顺序执行事务，如下

watch 监控

watch 就是用来监控某个 key 是否在事务执行之前，发生改变，但必须搭配事务来使用.

如下，用 watch 监控 key1，开启事务，并在执行事务之前，另一个客户端对 key1 进行修改，如下

执行事务后，发现 key 在外部由修改，会返回 nil ，表示事务什么都不会执行，如下

watch 实现原理

watch 的实现，类似于一个 “乐观锁”.

乐观锁，不是某个具体的锁，而是指某一类锁的特性：加锁之前，就会有一个心里预期，预期接下来锁冲突的概论比较低，就像是有些同学，考试前觉得自己平时学的很扎实，因此考试前就轻松一些，少复习一点~

redis 的 watch 就相当于基于 “版本号” 这样的机制，实现 “乐观锁”。

当执行 watch key 的时候，就会给 key 安排一个 版本号，版本号可以理解成一个“整数”，每次在修改 key 的时候，版本号都会 “变大” （这个变大是没有规律的，不是每次都增长1），然后在执行 事务 的时候，就会做出判定，判断当前这个 key 的版本号和最初 watch 的时候，记录的版本号是否一致~

1. 如果一致，说明当前 key 在事务开启到最终执行这个过程中，没有别的客户端修改，才能真正的执行事务.
2. 如果不一致，就说明 key 在其他客户端修改过了，因此就直接丢弃事务中的所有操作，最后返回 nil.

Ps：这样的设定，在 CAS 的 ABA 问题中也涉及到过，思想方法和实现上都是非常相似的，例如 CAS 实现自旋锁，就类似版本号设定的实现.

小结

---

重在学习思想，而不是理论，很多思想都是触类旁通的，当我们未来遇到某一类问题的时候，就可以回想起当时解决问题的思想方法，迎刃而解~