6、Redis事务、管道、发布订阅（了解）

梦里梦外; 2023-10-13 08:32 59阅读 0赞

1、Redis事务

是什么？  
可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞

一个队列中，一次性、顺序性、排他性的执行一系列命令

Redis事务和数据库事务  
![在这里插入图片描述][11b4955811fb4d44b93f2fe8317ffdd9.png]  
Redis事务命令

# 开启事务，redis会将后续的命令逐个放入队列中，然后使用EXEC命令来原子化执行这个命令系列。
    MULTI   
    
    # 执行事务中的所有操作命令。
    EXEC    
    
    # 取消事务，放弃执行事务块中的所有命令。
    DISCARD
    
    # 监视一个或多个key,如果事务在执行前，这个key(或多个key)被其他命令修改，则事务被中断，不会执行事务中的任何命令。
    WATCH key [key ...]  
    
    # 取消WATCH对所有key的监视。
    UNWATCH

案例  
正常执行

# 开启事务
    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)> EXEC
    1) OK
    2) OK
    127.0.0.1:6379> keys *
    1) "k1"
    2) "k2"
    127.0.0.1:6379>

放弃事务

# 开启事务
    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 v23
    QUEUED
    # 取消事务
    127.0.0.1:6379(TX)> DISCARD
    OK
    127.0.0.1:6379> keys *
    (empty array)
    127.0.0.1:6379>

全体连坐

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 k33
    (error) ERR wrong number of arguments for 'set' 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> keys *
    (empty array)
    127.0.0.1:6379>

冤头债主

127.0.0.1:6379> MULTI
    OK
    127.0.0.1:6379(TX)> set k1 v1
    QUEUED
    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)> EXEC
    1) OK
    # 前期语法都没错，编译通过；执行exec后报错：冤有头，债有主对的执行错的停
    2) (error) ERR value is not an integer or out of range
    3) OK
    127.0.0.1:6379> keys *
    1) "k1"
    2) "k2"
    127.0.0.1:6379>

watch 监控

Redis使用Watch来提供乐观锁定，类似于CAS(Check-and-Set)

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据。

乐观锁策略:提交版本必须 大于 记录当前版本才能执行更新

127.0.0.1:6379> get k1
    "abc"
    127.0.0.1:6379> get balance
    OK
    # 监控
    127.0.0.1:6379> WATCH balance
    OK
    127.0.0.1:6379> MULTI
    OK
    127.0.0.1:6379(TX)> set k1 v1
    QUEUED
    127.0.0.1:6379(TX)> set balance 110
    QUEUED
    127.0.0.1:6379(TX)> get k1
    QUEUED
    127.0.0.1:6379(TX)> get balance
    QUEUED
    127.0.0.1:6379(TX)> EXEC
    1) OK
    2) OK
    3) "v1"
    4) "110"
    127.0.0.1:6379>

总结
    
    开启：以MULTI开始一个事务
    入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面
    执行：由EXEC命令触发事务

2、Redis管道  
是什么？  
管道(pipeline)可以一次性发送多条命令给服务端，服务端依次处理完完毕后，通过一条响应一次性将结果返回，通过减少客户端与redis的通信次数来实现降低往返延时时间。pipeline实现的原理是队列，先进先出特性就保证数据的顺序性。

批处理命令变种优化措施，类似Redis的原生批命令（mget和mset)  
![在这里插入图片描述][c15847c053ee470faa26a6dcbd0e2bda.png]

cat >> cmd.txt <<EOF
    set k100 v100
    set k200 v200
    hset k300 name haha
    hset k300 age 20
    hset k300 gender male
    EOF
    
    
    cat cmd.txt | redis-cli -a 123456 --pipe
    
    
    redis-cli -a 123456
    127.0.0.1:6379> get k100
    "v100"

总结  
Pipeline与原生批量命令对比

原生批量命令是原子性（例如：mset,mget）,pipeline是非原子性  
原生批量命令一次只能执行一种命令，pipeline支持批量执行不同命令  
原生批命令是服务端实现，而pipeline需要服务端与客户端共同完成  
Pipeline与事务对比

事务具有原子性，管道不具有原子性  
管道一次性将多条命令发送到服务器，事务是一条一条的发，事务只有在接收到exec命令后才会执行,管道不会  
执行事务时会阻塞其他命令的执行，而执行管道中的命令时不会  
使用Pipeline注意事项

pipeline缓冲的指令只是会依次执行，不保证原子性，如果执行中指令发生异常，将会继续执行后续的指令  
使用pipeline组装的命令个数不能太多，不然数据量过大客户端阻塞的时间可能过久，同时服务端此时也被迫回复一个队列答复，占用很多内存

3、Redis发布订阅（了解即可）  
是什么？  
是一种消息通信模式：发送者（PUBLISH）发送消息，订阅者（SUBSCRIBE）接收消息，可以实现进程间的消息传递

Redis可以实现消息中间件MQ的功能，通过发布订阅实现消息的引导和分流。仅代表我个人，不推荐使用该功能，专业的事情交给专业的中间件处理，redis就做好分布式缓存功能

发布/订阅其实是一个轻量的队列，只不过数据不会被持久化，一般用来处理实时性较高的异步消息

能干嘛？  
Redis客户端可以订阅任意数量的频道，类似我们微信关注多个公众号  
![在这里插入图片描述][e221fe45bd4348679f3e1b06a1bbbd8d.png]  
常用命令

##### 基于频道
    # 订阅给定的一个或多个频道
    subscribe channel  [channel ... ]
    
    # 退订给定的频道
    unsubscribe  channel  [channel ... ]
    # 说明：若没有指定channel，则默认退订所有频道
    
    # 将消息发送给指定频道 channel ， 返回结果：接收到信息的订阅者数量，无订阅者返回0
    publish channel message 
    
    
    # 查看订阅与发布系统的状态
    pubsub channels [argument  [atgument ...] ]
    # 说明：返回活跃频道列表（即至少有一个订阅者的频道，订阅模式的客户端除外）
    
    ##### 基于模式
    
    # 订阅一个或多个符合给定模式的频道
    psubscribe pattern1  [pattern...]
    #说明：每个模式以 * 作为匹配符；例如 cn* 匹配所有以cn开头的频道：cn.java、cn.csdn
    
    # 退订所有给定模式的频道
    punsubscribe [pattern [pattern ...] ] 
    # 说明：pattern 未指定，则订阅的所有模式都会被退订，否则只退订指定的订阅的模式

案例演示  
基于频道(Channel)的发布/订阅

--------------------------客户端1（订阅者） ：订阅频道 ---------------------
     
    # 订阅 “meihuashisan” 和 “csdn” 频道（如果不存在则会创建频道）
    127.0.0.1:6379> subscribe meihuashisan csdn 
    Reading messages... (press Ctrl-C to quit)
     
    1) "subscribe"    -- 返回值类型：表示订阅成功！
    2) "meihuashisan" -- 订阅频道的名称
    3) (integer) 1    -- 当前客户端已订阅频道的数量
     
    1) "subscribe"
    2) "csdn"
    3) (integer) 2
     
    #注意：订阅后，该客户端会一直监听消息，如果发送者有消息发给频道，这里会立刻接收到消息
    
    
    
    
    --------------------------客户端2（发布者）：发布消息给频道 -------------------
     
     
    # 给“meihuashisan”这个频道 发送一条消息：“I am meihuashisan”
    127.0.0.1:6379> publish meihuashisan "I am meihuashisan"
    (integer) 1  # 接收到信息的订阅者数量，无订阅者返回0
    
    
    
    
    # --------------------------客户端1（订阅者） ：订阅频道 -----------------
     
    127.0.0.1:6379> subscribe meihuashisan csdn 
    Reading messages... (press Ctrl-C to quit)
     
    1) "subscribe"    -- 返回值类型：表示订阅成功！
    2) "meihuashisan" -- 订阅频道的名称
    3) (integer) 1    -- 当前客户端已订阅频道的数量
     
    1) "subscribe"
    2) "csdn"
    3) (integer) 2
     
     
     
     ---------------------变化如下：（实时接收到了该频道的发布者的消息）------------
     
    1) "message"           -- 返回值类型：消息
    2) "meihuashisan"      -- 来源（从哪个频道发过来的）
    3) "I am meihuashisan" -- 消息内容

基于模式(pattern)的发布/订阅  
订阅者订阅频道 psubscribe pattern \[pattern …\]

--------------------------客户端1（订阅者） ：订阅频道 ---------------------
     
     
    #  1. ------------订阅 “a?” "com.*" 2种模式频道--------------
    127.0.0.1:6379> psubscribe a? com.*
    # 进入订阅状态后处于阻塞，可以按Ctrl+C键退出订阅状态
    Reading messages... (press Ctrl-C to quit) 
     
     
     
    # 2. ---------------订阅成功-------------------
     
    1) "psubscribe"  -- 返回值的类型：显示订阅成功
    2) "a?"          -- 订阅的模式
    3) (integer) 1   -- 目前已订阅的模式的数量
     
     
    1) "psubscribe"
    2) "com.*"
    3) (integer) 2
     
     
     
    # 3. ---------------接收消息 （已订阅 “a?” "com.*" 两种模式！）-----------------
     
    # ---- 发布者第1条命令： publish ahead "hello"
    结果：没有接收到消息，匹配失败，不满足 “a?” ，“？”表示一个占位符， a后面的head有4个占位符
     
     
    # ---- 发布者第2条命令：  publish aa "hello" （满足 “a?”）
    1) "pmessage" -- 返回值的类型：信息
    2) "a?"       -- 信息匹配的模式：a?
    3) "aa"       -- 信息本身的目标频道：aa
    4) "hello"    -- 信息的内容："hello"
     
     
    # ---- 发布者第3条命令：publish com.juc "hello2"（满足 “com.*”, *表示任意个占位符）
    1) "pmessage" -- 返回值的类型：信息
    2) "com.*"    -- 匹配模式：com.*
    3) "com.juc"  -- 实际频道：com.juc
    4) "hello2"   -- 信息："hello2"
     
    # ---- 发布者第4条命令： publish com. "hello3"（满足 “com.*”, *表示任意个占位符）
    1) "pmessage" -- 返回值的类型：信息
    2) "com.*"    -- 匹配模式：com.*
    3) "com."     -- 实际频道：com.
    4) "hello3"   -- 信息："hello3"

发布者发布消息 publish channel message

--------------------------客户端2（发布者）：发布消息给频道 -------------------
     
    注意：订阅者已订阅 “a?” "com.*" 两种模式！
     
     
    # 1. ahead 不符合“a?”模式，?表示1个占位符
    127.0.0.1:6379> publish ahead "hello"  
    (integer) 0    -- 匹配失败，0:无订阅者
     
     
    # 2. aa 符合“a?”模式，?表示1个占位符
    127.0.0.1:6379> publish aa "hello"      
    (integer) 1
     
    # 3. 符合“com.*”模式，*表示任意个占位符
    127.0.0.1:6379> publish com.juc "hello2" 
    (integer) 1
     
    # 4. 符合“com.*”模式，*表示任意个占位符
    127.0.0.1:6379> publish com. "hello3" 
    (integer) 1

Pub/Sub缺点

发布的消息在Redis系统中不能持久化，因此，必须先执行订阅，再等待消息发布。如果先发布了消息，那么该消息由于没有订阅者，消息将被直接丢弃

消息只管发送对于发布者而言消息是即发即失的，不管接收，也没有ACK机制，无法保证消息的消费成功。

以上的缺点导致Redis的Pub/Sub模式就像个小玩具，在生产环境中几乎无用武之地，为此Redis5.0版本新增了Stream数据结构，不但支持多播，还支持数据持久化，相比Pub/Sub更加的强大

[11b4955811fb4d44b93f2fe8317ffdd9.png]: https://img-blog.csdnimg.cn/11b4955811fb4d44b93f2fe8317ffdd9.png
[c15847c053ee470faa26a6dcbd0e2bda.png]: https://img-blog.csdnimg.cn/c15847c053ee470faa26a6dcbd0e2bda.png
[e221fe45bd4348679f3e1b06a1bbbd8d.png]: https://img-blog.csdnimg.cn/e221fe45bd4348679f3e1b06a1bbbd8d.png