Redis的发布订阅模式
Redis的发布订阅模式
什么是发布订阅
任务队列：顾名思义，就是“传递消息的队列”。与任务队列进行交互的实体有两类，一类是生产者（producer），另一类则是消费者（consumer）。生产者将需要处理的任务放入任务队列中，而消费者则不断地从任务独立中读入任务信息并执行。
发布订阅模式
其实从Pub/Sub的机制来看，它更像是一个广播系统，多个订阅者（Subscriber）可以订阅多个频道（Channel），多个发布者（Publisher）可以往多个频道（Channel）中发布消息。
可以这么简单的理解：
1）Subscriber：收音机，可以收到多个频道，并以队列方式显示
2）Publisher：电台，可以往不同的FM频道中发消息
3）Channel：不同频率的FM频道
发布订阅模式分类
- 一个发布者，多个订阅者
如下图所示，可以作为消息队列或者消息管道。
主要应用：通知、公告
- 多个发布者，一个订阅者
可以将PubSub做成独立的HTTP接口，各应用程序作为Publisher向Channel中发送消息，Subscriber端收到消息后执行相应的业务逻辑，比如写数据库，显示等等。
主要应用：排行榜、投票、计数。
- 多个发布者，多个订阅者
故名思议，就是可以向不同的Channel中发送消息，由不同的Subscriber接收。
主要应用：群聊、聊天。
发布订阅操作
1）PUBLISH channel msg
将信息 message 发送到指定的频道 channel
2）SUBSCRIBE channel [channel ...]
订阅频道，可以同时订阅多个频道
3）UNSUBSCRIBE [channel ...]
取消订阅指定的频道, 如果不指定频道，则会取消订阅所有频道
4）PSUBSCRIBE pattern [pattern ...]
订阅一个或多个符合给定模式的频道，每个模式以 * 作为匹配符，比如 it* 匹配所 有以 it 开头的频道( it.news 、 it.blog 、 it.tweets 等等)， news.* 匹配所有 以 news. 开头的频道( news.it 、 news.global.today 等等)，诸如此类
5）PUNSUBSCRIBE [pattern [pattern ...]]
退订指定的规则, 如果没有参数则会退订所有规则
6）PUBSUB subcommand [argument [argument ...]]
查看订阅与发布系统状态
_注意：_使用发布订阅模式实现的任务队列，当有客户端订阅channel后只能收到后续发布到该频道的消息，之前发送的不会缓存，必须Provider和Consumer同时在线。
## 1.订阅fm9922频道
SUBSCRIBE fm9922
# 2.发布者，往fm9922频道发消息
publish fm9922 'today is a good day'
一个订阅者订阅多个频道
# 1.订阅多个频道
127.0.0.1:6379> PSUBSCRIBE *
# 2.发布
127.0.0.1:6379> publish fm9922 'kiss kiss'
(integer) 1
127.0.0.1:6379> publish fm9944 "kiss kiss"
(integer) 1
127.0.0.1:6379> publish fm9955 "kiss kiss"
(integer) 1
多个订阅者订阅一个频道
## 多个订阅者
127.0.0.1:6379> SUBSCRIBE fm6688
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "fm6688"
3) (integer) 1
1) "message"
2) "fm6688"
3) "kiss kiss"
127.0.0.1:6379> SUBSCRIBE fm6688
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "fm6688"
3) (integer) 1
1) "message"
2) "fm6688"
3) "kiss kiss"
## 发布者
127.0.0.1:6379> publish fm6688 "kiss kiss"
(integer) 2
发布订阅模式和消息队列对比
客户端在执行订阅命令之后进入了订阅状态，只能接收 SUBSCRIBE 、PSUBSCRIBE、 UNSUBSCRIBE 、PUNSUBSCRIBE 四个命令。 开启的订阅客户端，无法收到该频道之前的消息，因为 Redis 不会对发布的消息进行持久化。 和很多专业的消息队列系统（例如Kafka、RocketMQ、RabbitMQ）相比，Redis的发布订阅略显粗糙。
例如:无法实现消息堆积和回溯。但胜在足够简单，如果当前场景可以容忍的这些缺点，也不失为一个不错的选择。
