Redis系列(十三)、pub/sub发布与订阅（对比List和Kafka）

最新推荐文章于 2025-02-21 14:13:16 发布
最新推荐文章于 2025-02-21 14:13:16 发布
阅读量3.2k 收藏 9
点赞数 7
分类专栏： # Redis 文章标签： redis 发布订阅 kafka List publish
本文为博主原创文章，转载请注明出处http://blog.csdn.net/wsdc0521
本文链接：https://blog.csdn.net/wsdc0521/article/details/106765933
版权

在前面的文章中或多或少有提到Redis的publish命令，它就是Redis中的发布订阅中的一个命令，本篇就介绍Redis中的发布订阅模式，以及对比使用List实现的消息队列和传统消息队列Kafka的区别。

目录

介绍

使用

对比

对比List

对比Kafka

Redis6系列文章：

Redis系列(一)、CentOS7下安装Redis6.0.3稳定版

Redis系列(二)、数据类型之字符串String 

Redis系列(三)、数据类型之哈希Hash

Redis系列(四)、数据类型之列表List

Redis系列(五)、数据类型之无序集合Set

Redis系列(六)、数据类型之有序集合ZSet(sorted_set)

Redis系列(七)、常用key命令

Redis系列(八)、常用服务器命令 

Redis系列(九)、Redis的“事务”及Lua脚本操作

Redis系列(十)、详解Redis持久化方式AOF、RDB以及混合持久化

Redis系列(十一)、Redis6新特性之ACL安全策略（用户权限管理）

Redis系列(十二)、Redis6集群搭建及原理(主从、哨兵、集群)

介绍

Redis中的订阅、发布实现了发布/订阅消息范式，发布者不是计划发送消息给特定的订阅者，而是发布消息到不同的频道，发布者不需要知道是哪些订阅者订阅了消息。订阅者对一个或多个频道感兴趣，只需接收感兴趣的消息，不需要知道是什么样的发布者发布的消息。这种发布者和订阅者的解耦合可以带来更大的扩展性和更加动态的网络拓扑。

在Redis的发布订阅模式中，有三个部分：

Publisher（发布者）：发送消息到频道中，每次只能往一个频道发送一条消息；

Subscriber（订阅者）：订阅频道，订阅者可以同时订阅多个频道；

Channel（频道）：将发布者发布的消息转发给当前订阅此频道的订阅者；

使用

发布订阅的命令如下：

#发布消息到指定的频道
PUBLISH channel message

#订阅给定的一个或多个频道的信息
SUBSCRIBE channel [channel ...]

#订阅一个或多个符合给定模式的频道
PSUBSCRIBE pattern [pattern ...] 

#指退订给定的频道
UNSUBSCRIBE [channel [channel ...]] 

#退订所有给定模式的频道
PUNSUBSCRIBE [pattern [pattern ...]] 

#查看订阅与发布系统状态
PUBSUB subcommand [argument [argument ...]]

我们使用上篇文章中搭建的集群来测试Redis的订阅发布模式，A节点作为发布者，A,B,C节点作为订阅者消费A节点发布的消息：

订阅者6381：与发布者在同一节点，订阅www,csdn,wyk三个频道；

订阅者6382：订阅符合csdn*和wyk*模式的所有频道；

订阅者6383：订阅csdn频道；

发布者6381：分别往csdn1,csdn2,csdn,wyk四个频道发送消息，验证三个订阅者接收消息的情况以及发布者发布消息后的返回值；

断开后的订阅者重新订阅后会丢失断开期间发布者发布的消息：

在集群模式中，发布者发布消息后的返回值取决于订阅者与发布者在不在同一个节点上：

发布者发布消息后返回值为与发布者相同节点当前订阅了该频道的客户端数量。

对比

在上面的示例中，大家也可以看到，Redis中的发布订阅非常像消息队列，但还是有不同，我们就来对比一下Redis的List实现消息队列以及传统消息队列Kafka看看有哪些不同：

对比List

与Redis中的List对比，基于List实现的消息队列需要结合lpush + brpop来实现。

胜（多消费组）：当多个客户端同时消费同一个List消息队列时，消费者A使用brpop消费的数据就从list中弹出了，消费者B就再也读不到该数据，而在发布订阅中，多个订阅者可以订阅相同的频道，频道内的数据会分发到各个订阅者，不会出现某一个订阅者消费了之后，另一个订阅者读不到该数据的情况。

负（断点消费）：但对于List的消息队列来说，当消费者断开后重连，仍然可以从List中断点消费还没消费的数据，而发布订阅中，如果订阅者断开重连，会丢失断开期间发布者发布的数据，无法恢复。

对比Kafka

Redis的发布订阅以及List并不是要和专业的消息队列对标，而是可以实现类似的功能，真正在消息队列领域做的好的有很多，RabbitMQ,ActiveMQ,RocketMQ,Kafka,Pulsar等等，发布订阅相比于它们有什么异同呢？

不同点：

持久化：Kafka会将数据持久化到磁盘内，而Redis的发布订阅做不到；

断点消费：上面也提到，当订阅者断开重连会丢失断开期间发布者发布的消息，而kafka中会记录每个消费者消费的topic的offset，因此kafka可以从断开的offset继续消费；

偏移量：基于上一条，同样的kafka的消费者可以指定从某个offset开始重新消费，而Redis发布订阅根本不会记录订阅者消费的偏移量； 

消费方式： 在Redis发布订阅中，数据消费情况是由发布者控制的，当发布者发布到频道中后，只有当前连接了频道的订阅者才能消费到数据，断开重连的会失去那部分数据。而kafka中消费进度是由消费者控制的，消费者从topic中拉取数据并记录消费的offset。

相同点：

消息模型：在JMS消息模型中有点对点和订阅发布两种，Kafka和Redis发布订阅都是采用发布订阅的模型。

消费者组：Kafka里在不同的消费者组中的消费者消费相同的topic时会各自维护一个offset，因此不会出现A消费之后的数据，B就消费不到的情况。Redis中订阅者订阅相同的频道也不会出现类似的情况。

 

希望本文对你有帮助，请点个赞鼓励一下作者吧~ 谢谢！

替代Mq_Springboot中基于Redis的Pub/Sub_以及Stream实现两种消息队列_加上之前的List消息队列这回够用了---SpringCloud工作笔记173
添柴程序猿的专栏
06-16 631
做项目的时候,有些生产环境对于中间件要求要尽可能少的使用,Redis一般不可或缺,但是kafka等不让安装....那么,用redis代替kafka,来实现消息队列.一.先看利用redis的基于pub/sub订阅消费实现的消息队列,这里每个订阅某个主题的消费者都 可以收到该主题中的所有消息. 1.添加项目依赖 2.新建一个消息监听器 3.配置一下订阅,我们来订阅一下message.pubsub这个主题的消息 4.发布消息,发布消息以后,消息监听器,就可以监听到,我们配置的订阅的消息队列的
Kafka、RabbitMQ、RocketMQ等消息中间件的介绍和对比
热门推荐
Brave Soul Blog
06-04 11万+
原文：http://jm.taobao.org/2016/04/01/kafka-vs-rabbitmq-vs-rocketmq-message-send-performance/?utm_source=tuicool&utm_medium=referral 分布式系统中,我们广泛运用消息中间件进行系统间的数据交换,便于异步解耦。现在开源的消息中间件有很多,前段时间我们自家的产品 ...
Redis Pub/Sub 与 Kafka、RabbitMQ 的优劣势对比
maply的博客
01-08 518
本文介绍了Redis 的 Pub/Sub 和 Kafka、RabbitMQ 等消息中间件在不同方面的对比分析，包括优劣势。
【笔记01】【Redis Stream 使用】
猫吻鱼的博客
02-21 1312
Redis Stream 是Redis 5.0消息队列：Redis Stream 可以用作高性能的消息队列。生产者可以将消息添加到流中，消费者可以从流中读取消息进行处理。它支持消费者组的概念，多个消费者可以组成一个组共同消费消息，并且可以记录每个消费者组的消费进度，确保消息不会被重复消费或遗漏。有序日志记录：Stream 中的消息是有序的，每个消息都有一个唯一的 ID，这个 ID 按照添加的顺序递增。这使得它非常适合用于记录系统的操作日志、事件日志等。
Redis 发布订阅，小功能大用处，真没那么废材！
楼下小黑哥
09-23 1754
今天小黑哥来跟大家介绍一下 Redis 发布/订阅功能。 也许有的小伙伴对这个功能比较陌生，不太清楚这个功能是干什么的，没关系小黑哥先来举个例子。 假设我们有这么一个业务场景，在网站下单支付以后，需要通知库存服务进行发货处理。 上面业务实现不难，我们只要让库存服务提供给相关的给口，下单支付之后只要调用库存服务即可。 后面如果又有新的业务，比如说积分服务，他需要获取下单支付的结果，然后增加用户的积分。 这个实现也不难，让积分服务同样提供一个接口，下单支付之后只要调用库存服务即可。 如果就两个业务需要获.
redis的list作消息队列和发布订阅系统的区别
begin2017的博客
06-29 742
啊
kafka redis vs 发布订阅_发布&订阅的消息系统 Kafka的深度解析
weixin_39747296的博客
12-21 341
背景介绍Kafka简介Kafka是一种分布式的，基于发布/订阅的消息系统。主要设计目标如下：以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输同时支持离线数据处理和实时数据处理为...
kafka redis vs 发布订阅_对比平台--Redis Vs Kafka 之间的区别
weixin_39744894的博客
12-21 305
Redis和Kafka之间的区别在本文中，我们将探讨Redis与Kafka之间的最高差异和性能。Redis： Redis是一个内存中的键值数据存储，也是开源的。它可以非常快地用于缓存会话管理，高性能数据库和消息代理。在存储和多种功能方面，Redis与Kafka有所不同。Apache Kafka： Apache Kafka是一个消息传递系统，它使您可以发布和订阅基于主题和分区的消息流。这样，它类...
kafka sqs 与_我正在评估Google PUB / SUB与Kafka？
weixin_39535752的博客
12-19 391
除了Google的Pub / Sub由Google管理和Kafka是开源的之外，另一个区别是Google Pub / Sub是一个消息队列(例如Rabbit MQ)，因为Kafka更像是流日志。 您不能使用Pubsub来“重读”或“重播”消息。 (编辑-从2019年2月开始，您可以按以下评论重播消息并向后追溯到特定时间戳)使用Google Pub / Sub，一旦从订阅中读取并确认了一条消息，它就...
Redis 发布订阅（Pub/Sub）机制详解
maply的博客
01-02 915
Redis 的 **发布订阅（Pub/Sub）机制** 是一种消息通信模式，允许消息的发送者（发布者）和接收者（订阅者）通过 **频道（Channel）** 进行通信。它是一种典型的 **发布-订阅模式**，Redis 的发布订阅机制非常适合简单的实时通信场景。
Redis-消息队列的三种方案（List、Streams、Pub-Sub）
2401_84091580的博客
05-03 2227
《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门，即可获取！现在回顾下，我们使用的消息队列，一般都有什么样的特点：撇开我们常用的消息中间件不说，你觉得 Redis 的哪些数据类型可以满足 MQ 的常规需求~~思来想去，只有 List 和 Streams 两种数据类型，可以实现消息队列的这些需求，当然，Redis 还提供了发布、订阅(pub/sub) 模式。我们逐一看下这 3 种方式的使用和场景。Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到
Redis实现发布/订阅功能（原理篇）
weixin_63944437的博客
09-11 1385
全网最详细的关于 Redis 实现消息订阅功能的讲解！！带各位从 Redis 本身命令行出发，再到框架集成实现写法。一篇文章带各位搞懂 Redis 的相关内容！！
Redis客户端之Jedis（Key、String、Set、List、pub/sub、cluster、pool、pipleline）
技术改变生活
07-15 2万+
原文链接：http://blog.csdn.net/xyang81/article/details/51918129环境： OS：CentOS7 64位 server版本：Redis 3.2.0 client 版本：Jedis 2.8.0在Maven中引用jedis的jar：<dependencies> <dependency> <groupId>jun
Kafka——使用java api进行pub & sub
weixin_34097242的博客
05-23 242
之前用过老的api,但是最近在写消费的时候，发现之前老的api很多方法都out了，又去官网看了下最新的0.10.x的api. 1，producer <dependency> <groupId>org.apache.kafka</groupId> <artifactId>kaf...
Apache Kafka工作流程| Kafka Pub-Sub Messaging
weixin_30871293的博客
05-11 349
1.目标 在我们上一篇Kafka教程中，我们讨论了Kafka Docker。今天，我们将讨论Kafka Workflow。此外，我们将详细介绍Pub-Sub Messaging的工作流程以及Queue Messaging / Consumer Group的工作流程。此外，我们将看到ZooKeeper在Apache Kafka中的作用。那么，让我们从Kafka Workflow开始吧。 Ap...
Confluent Kafka-PubSub-Community
weixin_40426261的博客
06-07 141
Confluent Kafka-PubSub-Community
Kafka使用场景
BlingBlingjuan的博客
04-28 3429
Kafka 使用场景
redis sub/pub
GJ_rabbit的博客
09-03 515
redis sub/pub 踩坑系列： 首先, 我们先了解相关知识 redis sub/pub(消息订阅) 是一种消息通信模式，pub是发送消息(生产者),，pub 是接收者(消费者)。其中，还隐藏着channel(通信频道)、联系，pub 通过多个 channel 发送给 sub，sub 最终进行消费 优劣对比 优势: 可监听多个通信频道, 可多个消费着消费 缺点: 数据可靠性无法保障, 因 pub 没有持久话 发送的消息是即发及丢, 无法确认 sub 接收到消息。 扩展性差: 不能通过及时增加消费者
kafka-1-消息中间件kafka的特性和由来
qq_20466211的博客
10-09 1341
kafka的发展
如何使用Redis Pub/Sub实现分布式环境下的通知机制
最新发布
04-03
<think>好的，我现在需要帮助用户了解如何使用Redis的发布订阅（Pub/Sub）功能在分布式系统中实现通知机制的最佳实践。首先，我应该回顾一下Redis Pub/Sub的基本概念和命令，比如PUBLISH、SUBSCRIBE、PSUBSCRIBE等，确保自己对这些基础内容有正确的理解。用户提到的引用[1]和[2]提到了Redis Pub/Sub与其他消息队列系统的对比，特别是扩展性和消息可靠性，这些可能在最佳实践中需要考虑。 接下来，我需要确定用户的具体需求。他们希望在分布式环境中实现通知机制，所以可能需要考虑多个服务实例之间的通信、消息的可靠传递、扩展性以及如何处理可能出现的故障。根据引用[1]，Redis的扩展性有限，所以可能需要建议如何克服这一点，比如分片或者结合其他技术。同时，消息可靠性也是一个关键点，因为Redis Pub/Sub不保证消息持久化，如果订阅者断开连接可能会丢失消息，所以需要提出解决方案，比如确认机制或补充持久化存储。 然后，我需要整理最佳实践的步骤。首先，频道设计，合理的命名空间和结构可以避免混乱。比如使用特定的前缀和层级结构，如“notifications:order:created”。其次，订阅者的实现，可能需要使用多路复用或者多线程来处理消息，避免阻塞。例如在Python中使用redis-py库，创建单独的线程来监听消息。同时，错误处理和重连机制也很重要，订阅者需要能够自动重新连接，防止网络问题导致的中断。 关于消息格式，建议使用结构化的数据，比如JSON，方便解析和扩展。同时，消息大小需要控制，避免影响性能。另外，消息确认机制可能需要引入额外的组件，比如结合Redis Streams来跟踪处理状态，或者使用数据库记录已处理的消息ID，确保消息不会丢失。 扩展性方面，由于Redis是单线程的，单个实例可能成为瓶颈，所以可以考虑分片策略，将不同的频道分配到不同的Redis实例上。或者使用集群模式，但需要注意Pub/Sub在集群中的行为，可能需要每个节点单独订阅。 监控和维护也是不可忽视的部分，需要记录消息的发布和订阅情况，使用Redis的监控命令或者集成外部监控工具。此外，设置合理的过期时间，避免频道堆积未处理的消息，尤其是在高负载情况下。 最后，需要考虑Redis Pub/Sub的适用场景。如果系统对消息可靠性要求极高，可能需要结合其他消息队列如Kafka或RabbitMQ，或者在发布消息的同时写入数据库备份，确保即使Redis出现问题，消息也能恢复。 总结这些点，我需要以清晰的结构将这些最佳实践分点列出，涵盖频道设计、订阅者实现、消息格式、确认机制、扩展性、监控、过期策略和适用场景。同时，生成的相关问题需要引导用户进一步探索，比如可靠性保障、扩展性方案、与Streams对比等。</think>### Redis Pub/Sub 实现分布式通知机制的最佳实践 #### 1. **频道设计与命名规范** - **层级化命名**：使用`:`分隔符定义频道层级，例如 `notifications:order:created`，便于分类管理[^2] - **命名空间隔离**：为不同业务模块添加前缀，如 `payment:success` 和 `inventory:low` - **通配符订阅**：通过 `PSUBSCRIBE notifications:*` 实现批量订阅相关频道 #### 2. **订阅者实现方案** ```python import redis import threading def message_handler(msg): print(f"收到通知: {msg['data']}") def subscribe_worker(): r = redis.Redis(host='redis-host', port=6379) pubsub = r.pubsub() pubsub.psubscribe('notifications:*') for msg in pubsub.listen(): if msg['type'] == 'pmessage': message_handler(msg) # 启动独立订阅线程 threading.Thread(target=subscribe_worker, daemon=True).start() ``` #### 3. **消息可靠性增强** - **消息格式标准化**：建议使用 JSON 结构化数据： $$\{ "event": "order_created", "timestamp": 1629999999, "data": \{...\} \}$$ - **补充持久化**：重要消息可同步写入 Redis Streams 或数据库[^1] - **心跳检测**：定期发送 `PING/PONG` 维持连接 #### 4. **扩展性优化** - **分片策略**：按业务维度分配不同 Redis 实例 ```bash # 订单类通知 redis-cli -h shard1 publish orders:update "{...}" # 库存类通知 redis-cli -h shard2 publish inventory:alert "{...}" ``` - **集群模式**：注意需在每个节点单独订阅 #### 5. **异常处理机制** - **自动重连**：在订阅循环中增加异常捕获 - **退避策略**：重连间隔采用指数退避算法 - **死信处理**：通过 `__keyspace@0__:频道名` 监听异常事件 #### 6. **监控指标** - 通过 `INFO PUBSUB` 获取活跃频道数 - 监控 `pubsub_patterns` 字段观察模式订阅数量 - 使用 `CLIENT LIST` 跟踪订阅者连接状态
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

王义凯_Rick

遇见即是缘，路过就给个评论吧~

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值