Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者 (pub) 发送消息，订阅者(sub) 接收消息 可以实现进程间的消息传递。这种模式非常适用于实时消息传递、事件通知和消息分发等场景
Redis可以实现消息中间件MQ的功能，通过发布订阅实现消息的引导和分流。但是目前不推荐使用该功能，专业的事情交给专业的中间件处理，redis就做好分布式缓存功能
Redis 客户端可以订阅任意数量的频道
1.如何使用Redis发布订阅
-
订阅频道 ：客户端可以使用
SUBSCRIBE命令订阅一个或多个频道。例如，SUBSCRIBE channel1 channel2订阅两个频道。 -
发布消息 ：使用
PUBLISH命令，发布者可以向指定频道发送消息，如PUBLISH channel1 "Hello World"。 -
接收消息：订阅了频道的客户端将接收到发布到这些频道的所有消息。
-
取消订阅 ：客户端可以使用
UNSUBSCRIBE命令来退订一个或多个频道
发布订阅的特点
-
解耦：发布者和订阅者之间是解耦的，发布者发送消息时不需要知道哪些订阅者会接收到这些消息。
-
动态：订阅者可以随时订阅或退订频道，而不需要重新启动服务或进行复杂的配置。
-
简单：Redis的发布订阅模型易于理解和实现，适合快速开发和部署。
2.发布和订阅流程图
客户端可以订阅频道如下图
当给这个频道发布消息后，消息就会发送给订阅的客户端
发布/订阅其实是一个轻量化的队列，只不过数据不会持久化，一般用来处理实时性较高的异步消息。
推荐先执行订阅然后再发布，订阅成功之前发布的消息是收不到的
3.操作命令
# 1. SUBSCRIBE channel [channel ...] 订阅给定的一个或多个频道的信息
# 订阅的客户端每次可以收到一个3个参数的消息
# 消息种类
# 始发频道的名称
# 实际的消息内容
127.0.0.1:6379> subscribe channel
# PUBLISH channel message 发布消息到指定的频道
127.0.0.1:6379> publish channel hello
# PSUBSCRIBE pattern [pattern ...]按照模式批量订阅，订阅一个或多个符合给定模式(支持*号？号之类的)的频道
127.0.0.1:6379> PSUBSCRIBE a* b?
# PUBSUB subcommand [argument [argument ...]] 查看订阅与发布系统
# PUBSUB CHANNELS 由活跃频道组成的列表
# PUBSUB NUMSUB [channel [channel ...]] 某个频道有几个订阅者
# PUBSUB NUMPAT 只统计使用PSUBSCRIBE命令执行的返回客户端订阅的唯一模式的数量
# UNSUBSCRIBE [channel [channel ...]] 退订给定的频道
# PUNSUBSCRIBE [pattern [pattern ...]] 退订所有给定模式的频道注：发布的消息没有持久化，如果在订阅的客户端收不到 hello，只能收到订阅后发布的消息
4.总结
可以实现消息中间件MQ的功能，通过发布订阅实现消息的引导和分流。但是不推荐使用该功能，专业的事情交给专业的中间件处理，redis就做好分布式缓存功能
PUB/SUB缺点
-
发布的消息在Redis系统中不能持久化，因此，必须先执行订阅，在等待消息发布。如果先发布了消息，那么该消息由于没有订阅者，消息将被直接丢弃
-
消息只管发送，对于发布者而言消息是即发即失，不管接受，也没有ACK机制，无法保证消息的消费成功
-
以上的缺点导致Redis的Pub/Sub模式就像个小玩具，在生产环境中几乎无用武之地，为此Redis5.0版本新增了Stream数据结构，不但支持多播，还支持数据持久化，相比Pub/Sub更加的强大
基于以上的缺点，在实际操作中需要考虑以下因素：
-
消息的持久化：Redis Pub/Sub本身不提供持久化，如果需要保证消息不丢失，可能需要额外的机制或使用其他数据结构如Streams。
-
消息的确认机制：Redis Pub/Sub不提供消息确认，如果需要确认消息已被订阅者成功处理，需要在应用层实现。
-
安全性：确保只有授权的订阅者可以接收敏感消息。
-
错误处理：实现错误处理机制，以便在消息传递过程中出现问题时能够恢复。
-
监控和日志：记录消息传递的日志，并使用监控工具来跟踪系统性能和健康状态。
感谢大家，请大家多多支持！