【Redis7】--4.事务、管道、发布和订阅
文章目录
- 事务
-
- 1.Redis事务
- 2.Redis事务特性
- 3.Redis事务命令
-
- 3.1MULTI
- 3.2EXEC
- 3.3DISCARD
- 3.4WATCH
- 3.5UNWATCH
- 4.不保证原子性
-
- 4.1"全体连坐"
- 4.2"冤头债主"
- 5.事务执行流程
- 管道
-
- 1.pipeline的使用
- 2.pipeline小总结
- 发布和订阅
-
- 1.常用命令
-
- 1.1SUBSCRIBE
- 1.2PUBLISH
- 1.3PSUBSCRIBE
- 1.4PUBSUB
- 1.5UNSUBSCRIBE
- 1.6 PUNSUBSCRIBE
- 2.总结
事务
1.Redis事务
Redis事务可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执行而不会被其他命令插入，不许加塞
在一个队列中，一次性、顺序性、排他性的执行一系列命令
Redis 事务使用 MULTI、EXEC、WATCH、DISCARD 和 UNWATCH 这些命令来实现。
2.Redis事务特性
Redis事务vs数据库事务
- 单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断
- 不保证原子性：Redis的事务不保证原子性，也就是不保证所有指令同时成功或同时失败，只有决定是否开始执行全部指令的能力，没有执行到一半进行回滚的能力
- 排他性：Redis会保证一个事务内的命令依次执行，不会被其他命令插入
3.Redis事务命令
MULTI：开启事务
EXEC：执行事务
DISCARD：取消事务
WATCH key [key ...]：监控指定的key
UNWATCH：取消监控。
3.1MULTI
标记一个事务块的开始。执行的命令都会放到一个队列中，通过EXEC命令统一执行。
3.2EXEC
执行事务队列中的命令。
3.3DISCARD
放弃事务。在开启了事务后，若不想执行命令了，可以通过DISCARD命令来取消事务。
3.4WATCH
监控指定的key的变化，要先开启监控，再开启事务。若监控的数据被篡改了，则事务中无法再对其修改，会返回nil。
执行完EXEC命令后，之前加的监控都会失效。
Redis使用Watch来提供乐观锁定，类似于CAS
回顾一下悲观锁、乐观锁：
悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。
乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据。
乐观锁策略:提交版本必须 大于 记录当前版本才能执行更新
初始化k1和balance两个key，先监控再开启multi，保证两个key变动在同一个事务内
有加塞篡改：
3.5UNWATCH
取消监控。在对某个key监控后，已经发现了它被篡改过了，可以使用unwatch命令取消对该key的监控。
4.不保证原子性
4.1"全体连坐"
要么都执行，要么都不执行。
4.2"冤头债主"
错误的命令报错归报错，正确的命令依旧执行，即使在错误命令之后也会执行。
注意和传统数据库事务区别，不一定要么一起成功要么一起失败
5.事务执行流程
（1）开启：以MULTI命令开启一个事务
（2）入队：将多个命令假如到事务队列中，接到这些命令并不会立即执行。
（3）执行：由EXEC命令执行事务队列中的命令。
管道
Redis 管道（Pipeline）是一种在客户端和 Redis 服务器之间建立的双向通道，它可以让客户端在一次请求中发送多个命令并一次性接收多个命令的响应结果。通过使用 Redis 管道，客户端可以减少网络通信的次数，从而提高 Redis 的吞吐量和性能。
在传统的 Redis 操作中，每个命令都需要通过网络发送到 Redis 服务器，然后等待 Redis 服务器返回响应结果后再进行下一个命令的操作，这样就会产生大量的网络通信开销。而使用 Redis 管道，客户端可以将多个命令一次性发送到 Redis 服务器，然后一次性接收所有命令的响应结果，从而减少网络通信的次数和开销。
批处理命令变种优化措施，类似Redis的原生批命令(mget和mset)
1.pipeline的使用
首先创建一个文件，写入需要执行的命令集。
在Linux终端使用cat cmd.txt | redis-cli -a 123456 --pipe命令将命令集传输到服务器。
(管道符”|“表示将前面命令的结果集作为参数传输给后面的命令)
2.pipeline小总结
-
Pipeline与原生批量命令对比：
- 原生批量命令（例如mset、mget）具有原子性，pipeline是非原子性。
- 原生批量命令一次只能执行一种命令，pipeline支持批量执行不同命令。
- 原生批命令是redis服务端实现，而pipeline需要redis服务端和客户端共同完成。
-
Pipeline与事务对比：
- 事务具有原子性，管道不具有原子性。
- 管道一次性将命令发送给服务器，事务是一条一条的发，事务只有在接收到EXEC命令后才会执行。
- 执行事务时会阻塞其他命令的执行，而执行管道中的命令不会。
-
使用Pipeline注意事项：
- pipeline缓冲的指令只是会依次执行，不保证原子性，如果执行中指令发生异常，还会继续执行后续的指令。
- 使用pipeline传输的命令也不能太多，如果数据量大客户端的阻塞时间可能会过久，同时服务端此时也被迫回复一个队列答复，占用很多内存。
发布和订阅
Redis发布和订阅(Publish/Subscribe，简称 Pub/Sub)是一种消息传递模式，用于在Redis中实现消息的发布和订阅，发送者发送消息，订阅者接收消息，可以实现进程之间的消息传递
在 Redis 中，发布者（Publisher）可以将消息发送到一个或多个频道（Channel），订阅者（Subscriber）可以订阅一个或多个频道，以接收发布者发送的消息。当发布者在某个频道上发布一条消息时，所有订阅该频道的订阅者都会收到这条消息。
Redis Pub/Sub 是基于消息传递的异步通信模型，可以用于构建实时系统、聊天室、实时广播等应用场景。
1.常用命令
1.1SUBSCRIBE
SUBSCRIBE channel [channel ...]：订阅一个或多个频道
一旦客户进入了订阅状态，客户端就只能接受订阅相关的命令SUBSCRIBE、PSUBSCRIBE、UNSUBSCRIBE和PUNSUBSCRIBE，除了这些命令，其他命令一律失效。按Ctrl+C结束订阅状态。
返回值：发布类型、频道名称、第几个频道
1.2PUBLISH
PUBLISH channel message：发布消息到指定频道。
返回值为收到消息的客户端数量。
1.3PSUBSCRIBE
PSUBSCRIBE pattern [pattern ...]：按照匹配模式批量订阅。
支持的模式有：?表示任意一个字符；
*表示任意数量的任意字符；[]表示中括号中的指定字符。比如：
h?llo：可以匹配hallo、hbllo、hello…
h*llo：可以匹配hello、heeello、habcdello…
h[abc]llo：只能匹配hallo、hbllo、hcllo
1.4PUBSUB
PUBSUB 是自省命令，能够检测PUB/SUB子系统的状态。
PUBSUB CHANNELS [pattern] ：返回当前活跃的频道。
只会统计使用SUBSCRIBE订阅的频道。
PUBSUB NUMSUB channel [channel ...]：返回指定频道订阅者的个数。
只会统计使用SUBSCRIBE订阅的订阅者个数。
PUBSUB UNMPAT：返回订阅模式(PSUBSCRIBE)的数量。
这个命令返回的不是订阅模式的订阅者数量， 而是所有Redis客户端(订阅者)订阅的所有模式的数量总和。
1.5UNSUBSCRIBE
UNSUBSCRIBE channel [channel ...]：指示客户端退订指定频道，若没有指定频道则退订所有频道。
1.6 PUNSUBSCRIBE
PUNSUBSCRIBE pattern [pattern ...]：指示客户端退订指定模式，若没有提供模式则退定所有模式。
2.总结
Redis可以实现消息中间件MQ的功能，通过发布订阅实现消息的引导和分流，但是专业的事情交给专业的中间件处理，redis主要做好分布式缓存功能
- 发布的消息在Redis系统不能持久化，因此必须先执行订阅，再等待消息发布，如果先发布了消息且该消息没有订阅者接收，那么该消息被直接丢弃。
- 消息只管发送，对于发布者而言消息是即发即失的，也没有ACK机制，无法保证消息是否消费成功。
- Redis5.0新增了Stream数据结构，不但支持多播，还支持数据持久化，比Pub/Sub更加强大。