文章目录
展开Redis 订阅发布模式
消息队列
消息队列(Message Queue)是一种应用间的通信方式,消息发送后可以立即返回,有消息系统来确保信息的可靠专递,消息生产者只管把消息发布到 MQ 中而不管谁来取,消息消费者只管从 MQ 中取消息而不管谁发布的,这样发布者和使用者都不用知道对方的存在。
消息队列的使用原因
首先,我们可以知道,消息队列是一种异步的工作机制,比如说日志收集系统,为了避免数据在传输过程中丢失,还有订单系统,下单后,会生成对应的单据,库存的扣减,消费信息的发送,一个下单,产生这么多的消息,都是通过一个操作的触发,然后将其他的消息放入消息队列中,依次产生。再就是很多网站的,秒杀活动之类的,前多少名用户会便宜,都是通过消息队列来实现的。
这些例子,都是通过消息队列,来实现,业务的解耦,最终数据的一致性,广播,错峰流控等等,从而完成业务的逻辑。
消息队列产品
- 1)rabbit-MQ(最初起源于金融系统,用于分布式系统中存储转发消息。OpenStack)
- 2)Zero-MQ(SaltStack)
- 3)Kafka(JAVA)
- 4)redis(key:value 数据库,缓存,消息队列)
拓展
VMware 集群化产品
VCenterServer 服务端
VspareClient 客户端
Linux 虚拟化产品
- VirtualBox
- KVM (OpenStack 是 KVM 的编排工具)
Redis 发布消息的两种模式
任务队列模式(queuing)
任务队列:顾名思义,就是 “传递消息的队列”。与任务队列进行交互的实体有两类,一类是发布者,另一类则是订阅者。发布者将需要处理的任务放入任务队列中,而订阅者则不断地从任务独立中读入任务信息并执行。
任务队列的好处
1)松耦合。
生产者和消费者只需按照约定的任务描述格式,进行编写代码。
2)易于扩展。
多消费者模式下,消费者可以分布在多个不同的服务器中,由此降低单台服务器的负载。
发布 - 订阅模式 (publish-subscribe)
其实从 Pub/Sub 的机制来看,它更像是一个广播系统,多个订阅者(Subscriber)可以订阅多个频道(Channel),多个发布者(Publisher)可以往多个频道(Channel)中发布消息。
可以这么简单的理解:
1)Subscriber:收音机,可以收到多个频道,并以队列方式显示
2)Publisher:电台,可以往不同的FM频道中发消息
3)Channel:不同频率的FM频道
Redis 发布订阅实践
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. 开头的频道等等),诸如此类
5)PUNSUBSCRIBE [pattern [pattern ...]]
退订指定的规则,如果没有参数则会退订所有规则
6)PUBSUB subcommand [argument [argument ...]]
查看订阅与发布系统状态
注意:使用发布订阅模式实现的消息队列,当有客户端订阅 channel 后只能收到后续发布到该频道的消息,之前发送的不会缓存,必须 Provider 和 Consumer 同时在线。
订阅发布模型
一个发布者多个订阅者模型
如下图所示,可以作为消息队列或者消息管道。
主要应用:通知、公告
# 先订阅到一个频道
127.0.0.1:6379> SUBSCRIBE FM888
1) "subscribe"
2) "FM888"
3) (integer) 1
# 发布者发布消息
127.0.0.1:6379> PUBLISH FM888 test1
(integer) 1
127.0.0.1:6379> PUBLISH FM888 test2
(integer) 2 (代表订阅个数)
# 订阅者们接收消息
127.0.0.1:6379(subscribed mode)> SUBSCRIBE FM888
1) "subscribe"
2) "FM888"
3) (integer) 1
1) "message"
2) "FM888"
3) "test1"
1) "message"
2) "FM888"
3) "test2"
多个发布者一个订阅者模型
可以将 PubSub 做成独立的 HTTP 接口,各应用程序作为 Publisher 向 Channel 中发送消息,Subscriber 端收到消息后执行相应的业务逻辑,比如写数据库,显示等等。
主要应用:排行榜、投票、计数。
# 订阅者订阅频道
127.0.0.1:6379(subscribed mode)> SUBSCRIBE FM888
# 发布者1
127.0.0.1:6379> PUBLISH FM888 test2
(integer) 1
# 发布者2
127.0.0.1:6379> PUBLISH FM888 test3
(integer) 1
# 订阅者
127.0.0.1:6379(subscribed mode)> SUBSCRIBE FM888
1) "subscribe"
2) "FM888"
3) (integer) 1
1) "message"
2) "FM888"
3) "test2"
1) "message"
2) "FM888"
3) "test3"
多个发布者多个订阅者模型
故名思议,就是可以向不同的 Channel 中发送消息,由不同的 Subscriber 接收。
主要应用:群聊、聊天。
# 订阅者们订阅频道
127.0.0.1:6379> PSUBSCRIBE *
# 发布者1
127.0.0.1:6379> PUBLISH FM3 test10
(integer) 1
# 发布者2
127.0.0.1:6379> PUBLISH FM888 test10
(integer) 1
# 发布者3
127.0.0.1:6379> PUBLISH FM888 test1
(integer) 1
# 发布者4
127.0.0.1:6379> PUBLISH FM12 test12
(integer) 1
# 订阅者们收到的消息
127.0.0.1:6379> PSUBSCRIBE *
1) "psubscribe"
2) "*"
3) (integer) 1
1) "pmessage"
2) "*"
3) "FM3"
4) "test10"
1) "pmessage"
2) "*"
3) "FM888"
4) "test10"
1) "pmessage"
2) "*"
3) "FM888"
4) "test1"
1) "pmessage"
2) "*"
3) "FM12"
4) "test12"
取消订阅操作
## 取消单个频道
127.0.0.1:6379> PSUBSCRIBE 频道
## 取消多个频道(*是取消所有频道)
127.0.0.1:6379> UNSUBSCRIBE 频道1 频道2
127.0.0.1:6379> UNSUBSCRIBE *
消息队列系统对比
## 取消单个频道
127.0.0.1:6379> PSUBSCRIBE 频道
## 取消多个频道(*是取消所有频道)
127.0.0.1:6379> UNSUBSCRIBE 频道1 频道2
127.0.0.1:6379> UNSUBSCRIBE *
客户端在执行订阅命令之后进入了订阅状态,只能接收 SUBSCRIBE 、PSUBSCRIBE、 UNSUBSCRIBE 、PUNSUBSCRIBE 四个命令。 开启的订阅客户端,无法收到该频道之前的消息,因为 Redis 不会对发布的消息进行持久化。 和很多专业的消息队列系统(例如 Kafka、RocketMQ、RabbitMQ)相比,Redis 的发布订阅略显粗糙。
例如:无法实现消息堆积和回溯。但胜在足够简单,如果当前场景可以容忍的这些缺点,也不失为一个不错的选择。
Comments | NOTHING