市场调查 网站建设,外链在线发布工具,线下营销推广方式都有哪些,网站的管理权限有什么用Redis 发布订阅 (pub/sub) 是一种消息通信模式#xff1a;发送者 (pub) 发送消息#xff0c;订阅者(sub) 接收消息 可以实现进程间的消息传递。这种模式非常适用于实时消息传递、事件通知和消息分发等场景
Redis可以实现消息中间件MQ的功能#xff0c;通过发布订阅实现消息…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不提供消息确认如果需要确认消息已被订阅者成功处理需要在应用层实现。 安全性确保只有授权的订阅者可以接收敏感消息。 错误处理实现错误处理机制以便在消息传递过程中出现问题时能够恢复。 监控和日志记录消息传递的日志并使用监控工具来跟踪系统性能和健康状态。 感谢大家请大家多多支持
