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

淡淡的烟草味﹌ 2024-03-23 19:02 38阅读 0赞

**目录**

一、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      放弃监控

#### 开启/执行/放弃事务 ####

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

![9412906aa19e40c4883d6b09487f9453.png][]

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

![961be672556440ccad6a5cb61c884731.png][]

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

![3517d65e52244e20bd0604361e724e90.png][]

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

![ed77666df38749b3a3bff15df205bf38.png][]

#### watch 监控 ####

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

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

![bfedcb8969a4481d85e2231fe6ea024d.png][]

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

![ab1de8667c58482489deb0082e7a18e6.png][]

#### watch 实现原理 ####

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

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

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

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

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

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

## 小结 ##

--------------------

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

[9412906aa19e40c4883d6b09487f9453.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/79fdfc2ffa8844f584643a1fd8040b74.png
[961be672556440ccad6a5cb61c884731.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/041127e825d74210a58c6b02f9498765.png
[3517d65e52244e20bd0604361e724e90.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/9490845206e9494d8188100a30dc85c9.png
[ed77666df38749b3a3bff15df205bf38.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/6397e110f1244ce2a3bb3e908bb27ed6.png
[bfedcb8969a4481d85e2231fe6ea024d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/258b8373eae34e6296a5543185386c07.png
[ab1de8667c58482489deb0082e7a18e6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/d636b677d84b4b44aead133815529d17.png