后端与系统架构2802 字

Redis发布订阅机制实现原理

·全库 527 / 611

《Redis发布订阅机制实现原理》共 0.3 万字,通篇围绕 Redis、场景、Kafka、安全 展开,归在「后端与系统架构」这一层。

覆盖Redis场景Kafka安全

适合给 AI 系统搭底座、要管得住的人

目录骨架(6 节)
  1. Redis发布订阅机制实现原理
  2. 这种方式存在两个局限性:
  3. ◇ 双端队列图解如下:
  4. ◇ 发布/订阅模式图解如下:
  5. Redis有两种发布/订阅模式:
  6. 基于频道(Channel)的发布/订阅

什么是发布订阅?

Redis 发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消息。

Redis 的 subscribe 命令可以让客户端订阅任意数量的频道, 每当有新信息发送到被订阅的频道时, 信息就会被发送给所有订阅指定频道的客户端。

☛ 下图展示了频道 channel1 , 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系:

image.png

☛ 当有新消息通过 publish 命令发送给频道 channel1 时, 这个消息就会被发送给订阅它的三个客户端:

image.png

☆ 为什么要用发布订阅?

熟悉消息中间件的同学都知道,针对消息订阅发布功能,市面上很多大厂使用的是kafka、RabbitMQ、ActiveMQ, RocketMQ等这几种,redis的订阅发布功能跟这三者相比,相对轻量,针对数据准确和安全性要求没有那么高可以直接使用,适用于小公司。

redis 的List数据类型结构提供了 blpop 、brpop 命令结合 rpush、lpush 命令可以实现消息队列机制,基于双端链表实现的发布与订阅功能

这种方式存在两个局限性:

  • 不能支持一对多的消息分发。
  • 如果生产者生成的速度远远大于消费者消费的速度,易堆积大量未消费的消息

◇ 双端队列图解如下:

image.png

✦解析:双端队列模式只能有一个或多个消费者轮着去消费,却不能将消息同时发给其他消费者

◇ 发布/订阅模式图解如下:

image.png

✦解析:redis订阅发布模式,生产者生产完消息通过频道分发消息,给订阅了该频道的所有消费

发布/订阅如何使用?

Redis有两种发布/订阅模式:

  • 基于频道(Channel)的发布/订阅
  • 基于模式(pattern)的发布/订阅

操作命令如下

image.png

基于频道(Channel)的发布/订阅

“发布/订阅” 包含2种角色:发布者和订阅者。发布者可以向指定的频道(channel)发送消息;订阅者可以订阅一个或者多个频道(channel),所有订阅此频道的订阅者都会收到此消息。

image.png

  • 订阅者订阅频道 subscribe channel [channel ...]
--------------------------客户端1(订阅者) :订阅频道 ---------------------
 
# 订阅 “tuling” 和 “csdn” 频道(如果不存在则会创建频道)
127.0.0.1:6379> subscribe tuling csdn 
Reading messages... (press Ctrl-C to quit)
 
1) "subscribe"    -- 返回值类型:表示订阅成功!
2) "tuling" -- 订阅频道的名称
3) (integer) 1    -- 当前客户端已订阅频道的数量
 
1) "subscribe"
2) "csdn"
3) (integer) 2
 
#注意:订阅后,该客户端会一直监听消息,如果发送者有消息发给频道,这里会立刻接收到消息
 
  • 发布者发布消息 publish channel message
--------------------------客户端2(发布者):发布消息给频道 -------------------

# 给“tuling”这个频道 发送一条消息:“I am tuling”
127.0.0.1:6379> publish tuling "I am tuling"
(integer) 1  # 接收到信息的订阅者数量,无订阅者返回0
 

客户端2 (发布者) 发布消息给频道后,此时我们再来观察 客户端1 (订阅者) 的客户端窗口变化:

资料里没有你的场景?

把你手上的数据和想解决的那个环节发上来,我们按具体情况回,不复述方法论。

发布需求