Redis学习【7】之发布_订阅命令和事务

「爱情、让人受尽委屈。」 2024-03-26 10:34 88阅读 0赞

#### 文章目录 ####

*  一 发布/订阅命令
 *   *  1.1 消息系统
     *  1.2 subscribe
     *  1.3 psubscribe
     *  1.4 publish
     *  1.5 unsubscribe
     *  1.6 punsubscribe
     *  1.7 pubsub
     *   *  1.7.1 pubsub channels
         *  1.7.2 pubsub numsub
         *  1.7.3 pubsub numpat
 *  二 Redis 事务
 *   *  2.1 Redis 事务特性
     *  Redis 事务实现
     *   *  2.1.1 三个命令
         *  2.1.2 基本使用
     *  2.2. Redis 事务异常处理
     *   *  2.2.1 语法错误
         *  2.2.2 执行异常
     *  2.3 Redis 事务隔离机制
     *   *  2.3.1 需要事务隔离机制的原因
         *  2.3.2 隔离的实现
         *  2.3.3 隔离的实现原理

## 一 发布/订阅命令 ##

### 1.1 消息系统 ###

*  发布/订阅（pub/sub），是一种消息通信模式：发布者【消息生产者】，生产和发送消息到存储系统；订阅者【消息消费者】，从存储系统接收和消费消息。**这个存储系统可以是文件系统 FS、消息中间件 MQ、数据管理系统 DBMS，也可以是 Redis。** 整个消息发布者、订阅者与存储系统称为消息系统。
 *  **消息系统中的订阅者订阅了某类消息后，只要存储系统中存在该类消息，其就可不断的接收并消费这些消息。当存储系统中没有该消息后，订阅者的接收、消费阻塞。而当发布者将消息写入到存储系统后，会立即唤醒订阅者**。当存储系统放满时，不同的发布者具有不同的处理方式：有的会阻塞发布者的发布，等待可用的存储空间；有的则会将多余的消息丢失。
 *  不同的消息系统消息的发布/订阅方式也是不同的。例如 **RocketMQ、Kafka 等消息中间件构成的消息系统中，发布/订阅的消息都是以主题 Topic 分类的。而 Redis 构成的消息系统中，发布/订阅的消息都是以频道 Channel 分类的。**  
    ![在这里插入图片描述][4e4b0d3a705b411d91f915fdae4042eb.png]

### 1.2 subscribe ###

*  格式：`SUBSCRIBE channel *channel …+`
 *  功能：**Redis 客户端通过一个 `subscribe` 命令可以同时订阅任意数量的频道。在输出了订阅主题后，命令处于阻塞状态，等待相关频道的消息。**  
    ![在这里插入图片描述][fd43dcf5dc154436999f343ad7f3ef7a.png]  
    ![在这里插入图片描述][148e617d590f43219ff31221d56cf3e8.png]

### 1.3 psubscribe ###

*  格式：`PSUBSCRIBE pattern *pattern …+`
 *  功能：**订阅一个或多个符合给定模式的频道**
 *  说明：**这里的模式只能使用通配符 `*`。** 如，`it*` 可以匹配所有以 it 开头的频道，如`it.news、it.blog、it.tweets` ；`news.*`可以匹配所有以 `news.`开头的频道。  
    ![在这里插入图片描述][a171744c4ffe4375b57e677400b03d1d.png]  
    ![在这里插入图片描述][5ccb985148b44492aeda28496ba15294.png]

### 1.4 publish ###

*  格式：`PUBLISH channel message`
 *  功能：**Redis 客户端通过一条 publish 命令可以发布一个频道的消息，返回值为接收到该消息的订阅者数量。**  
    ![在这里插入图片描述][c42f5d65039f49408d59e1b802109959.png]

### 1.5 unsubscribe ###

*  格式：`UNSUBSCRIBE *channel *channel …++`
 *  功能：**Redis 客户端退订指定的频道**
 *  说明：**如果没有频道被指定，会执行一个无参数的 `unsubscribe` 命令，客户端使用 `SUBSCRIBE` 命令订阅的所有频道都会被退订。在这种情况下，返回一个信息，告知客户端所有被退订的频道**  
    ![在这里插入图片描述][7453fce270fc4f7bb9df7a2657893951.png]

### 1.6 punsubscribe ###

*  格式：`PUNSUBSCRIBE *pattern *pattern …++`
 *  功能：**退订一个或多个符合给定模式的频道**
 *  说明：**这里的模式只能使用通配符 `*`。如果没有频道被指定，其效果与 SUBSCRIBE 命令相同，客户端将退订所有订阅的频道。**  
    ![在这里插入图片描述][a4aaefe29c444aa78fc3498c59b4a0f9.png]

### 1.7 pubsub ###

*  格式：`PUBSUB <subcommand> [argument *argument …++`
 *  功能：`PUBSUB` 是一个查看订阅与发布系统状态的内省命令集，它由数个不同格式的子命令组成

#### 1.7.1 pubsub channels ####

*  格式：`PUBSUB CHANNELS [pattern]`
 *  功能：列出当前所有的活跃频道。活跃频道指的是那些至少有一个订阅者的频道。
 *  说明：pattern 参数是可选的。如果不给出 pattern 参数，将会列出订阅/发布系统中的所有活跃频道。如果给出 pattern 参数，那么只列出和给定模式 pattern 相匹配的那些活跃频道。pattern 中只能使用通配符\*。  
    ![在这里插入图片描述][a8686a5b4e1043e2a5925456d9e36d91.png]

#### 1.7.2 pubsub numsub ####

*  格式：`PUBSUB NUMSUB [channel-1 … channel-N]`
 *  功能：返回给定频道的订阅者数量。不给定任何频道则返回一个空列表。  
    ![在这里插入图片描述][e29034a8dcc642ab8764973e6a7bbd5e.png]

#### 1.7.3 pubsub numpat ####

*  格式：`PUBSUB NUMPAT`
 *  功能：查询当前 Redis 所有客户端订阅的所有频道模式的数量总和  
    ![在这里插入图片描述][4abf4e7fc7804bd297010315da309b80.png]

## 二 Redis 事务 ##

*  **Redis 的事务的本质是一组命令的批处理。这组命令在执行过程中会被顺序地、一次性全部执行完毕，只要没有出现语法错误，这组命令在执行期间是不会被中断。**

### 2.1 Redis 事务特性 ###

*  **Redis 的事务仅保证数据的一致性，不具有像 DBMS 一样的 ACID 特性。**

>  *  不具备原子性：这组命令中的某些命令的执行失败不会影响其它命令的执行，不会引发回滚。
>  *  没有复杂的隔离级别：这组命令通过乐观锁机制实现了简单的隔离性。
>  *  与事务无关：**这组命令的执行结果是被写入到内存的，是否持久取决于 Redis 的持久化策略**。

### Redis 事务实现 ###

#### 2.1.1 三个命令 ####

*  Redis 事务通过三个命令进行控制。
    
     *  muti：开启事务
     *  exec：执行事务
     *  discard：取消事务

#### 2.1.2 基本使用 ####

*  下面是定义并执行事务的用法：事务执行后，再访问事务中定义的变量，其值是修改过后。  
    ![在这里插入图片描述][99fb4e0167b1414e9d86a8ea28fe9cfe.png]
 *  下面是定义但取消事务的举例：事务取消后，事务中的命令是没有执行的  
    ![在这里插入图片描述][bb31b4087a0b49c0924cfae293f2f73b.png]

### 2.2. Redis 事务异常处理 ###

#### 2.2.1 语法错误 ####

*  当事务中的命令出现语法错误时，整个事务在 exec 执行时会被取消  
    ![在这里插入图片描述][f9542a59e1ba4b95b93afa2170c7a87e.png]

#### 2.2.2 执行异常 ####

*  如果事务中的命令没有语法错误，但在执行过程中出现异常，**该异常不会影响其它命令的执行**。  
    ![在这里插入图片描述][bb7eb00500924d64bfb204edf89aa805.png]  
    ![在这里插入图片描述][4da594aeb92c43419adae9a394dd9fd3.png]

### 2.3 Redis 事务隔离机制 ###

#### 2.3.1 需要事务隔离机制的原因 ####

*  在并发场景下可能会出现多个客户端对同一个数据进行修改的情况，造成数据不一致的情况！
    
     *  如：有两个客户端 C 左与 C 右，C 左需要申请 40 个资源，C 右需要申请 30 个资源。它们首先查看了当前拥有的资源数量，即 resources 的值为50，都感觉资源数量可以满足自己的需求，于是修改资源数量，以占有资源。但结果却是资源出现了“超卖”情况。  
        ![在这里插入图片描述][21f2c65727b24ff4b64f33167914cc65.png]
 *  **Redis 事务通过乐观锁机制实现了多线程下的执行隔离**

#### 2.3.2 隔离的实现 ####

*  Redis 通过 watch 命令再配合事务实现了多线程下的执行隔离  
    ![在这里插入图片描述][79fc9447f5dd410e8bbb85d9f89b19ac.png]
 *  以上两个客户端执行的时间顺序为：  
    ![在这里插入图片描述][a3eb8beb841c4edaa00d475bcded7cbf.png]

#### 2.3.3 隔离的实现原理 ####

1.  当某一客户端对 key 执行了 watch 后，系统就会为该 key 添加一个 version 乐观锁，并初始化 version。例如初值为 1.0。
2.  此后客户端 C 左将对该 key 的修改语句写入到了事务命令队列中，虽未执行，但其将该key 的 value 值与 version 进行了读取并保存到了当前客户端缓存。此时读取并保存的是version 的初值 1.0。
3.  此后客户端 C 右对该 key 的值进行了修改，这个修改不仅修改了 key 的 value 本身，同时也增加了 version 的值，例如使其 version 变为了 2.0，并将该 version 记录到了该 key信息中。
4.  此后客户端 C 左执行 exec，开始执行事务中的命令。不过，其在执行到对该 key 进行修改的命令时，该命令首先对当前客户端缓存中保存的 version 值与当前 key 信息中的version 值。如果缓存 version 小于 key 的 version，则说明客户端缓存的 key 的 value 已经过时，该写操作如果执行可能会破坏数据的一致性。所以该写操作不执行  
    ![在这里插入图片描述][d65b1d7558ba41e484a02c0594859e44.png]

[4e4b0d3a705b411d91f915fdae4042eb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/9483c89ab4ba49cdaf62f5b3e8234e10.png
[fd43dcf5dc154436999f343ad7f3ef7a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/21e00a261f134980b2ea73dbe7752dbf.png
[148e617d590f43219ff31221d56cf3e8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/07498a14146e46a7b34a08937bba518e.png
[a171744c4ffe4375b57e677400b03d1d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/675a2484aa394b1aad9e97248d9e4a4f.png
[5ccb985148b44492aeda28496ba15294.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/76dabbb2c6dd45cd9c8ef35a98d3f96e.png
[c42f5d65039f49408d59e1b802109959.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/3240bafe8bd54c96ae6b0f04eb1c214d.png
[7453fce270fc4f7bb9df7a2657893951.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/df4e1709d248496dbd1760fb06176975.png
[a4aaefe29c444aa78fc3498c59b4a0f9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/5cf7f6df19444b5d8e058962d01fbb51.png
[a8686a5b4e1043e2a5925456d9e36d91.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/fcf493179d654ed599cbed4d54a0cba6.png
[e29034a8dcc642ab8764973e6a7bbd5e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/67052bbf196645b1aa79d8791bb2e1e4.png
[4abf4e7fc7804bd297010315da309b80.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/efd4d6b112d04ae099978894cd186d53.png
[99fb4e0167b1414e9d86a8ea28fe9cfe.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/719c28ecbdeb438dafbeb60b1fb97fc5.png
[bb31b4087a0b49c0924cfae293f2f73b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/6c5227ccbbeb4efabf66b4ca49d089da.png
[f9542a59e1ba4b95b93afa2170c7a87e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/c02eb47d4662449abc248a564e341650.png
[bb7eb00500924d64bfb204edf89aa805.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/2948da594ad44ead8df4fd6148bca371.png
[4da594aeb92c43419adae9a394dd9fd3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/dbaead4d633e4bdaa8a17c5aeeb04f85.png
[21f2c65727b24ff4b64f33167914cc65.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/3812ae681c08469082bb966e59097f31.png
[79fc9447f5dd410e8bbb85d9f89b19ac.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/09783ddff285423fb9be57c1a06e7cb6.png
[a3eb8beb841c4edaa00d475bcded7cbf.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/63a12848bc87479abb492927a63638d0.png
[d65b1d7558ba41e484a02c0594859e44.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/f2eb5f4d401a418eb2f94b1ac4c269b6.png