1、Redis事务
是什么？
可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞
一个队列中，一次性、顺序性、排他性的执行一系列命令
Redis事务和数据库事务
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)
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客户端可以订阅任意数量的频道，类似我们微信关注多个公众号
常用命令
##### 基于频道
# 订阅给定的一个或多个频道
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更加的强大