Redis发布和订阅

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不提供消息确认，如果需要确认消息已被订阅者成功处理，需要在应用层实现。
安全性：确保只有授权的订阅者可以接收敏感消息。
错误处理：实现错误处理机制，以便在消息传递过程中出现问题时能够恢复。
监控和日志：记录消息传递的日志，并使用监控工具来跟踪系统性能和健康状态。

感谢大家，请大家多多支持！