第三章· Redis消息队列

一.生产消费模型



1.什么是消息队列？

在生活中，其实有不少的例子，都相似消息队列。

好比：工厂生产出来的面包，交给超市，商场来出售，客户经过超市，商场来买面包，客户不会针对某一个工厂去选择，只管从超市买出来，工厂也不会管是哪个客户买了面包，只管生产出来以后，交给超市，商场来处理。

消息队列（Message Queue）是一种应用间的通讯方式，消息发送后能够当即返回，有消息系统来确保信息的可靠专递，消息生产者只管把消息发布到MQ中而无论谁来取，消息消费者只管从MQ中取消息而无论谁发布的，这样发布者和使用者都不用知道对方的存在。

2.为何要使用消息队列呢？

首先，咱们能够知道，消息队列是一种异步的工做机制，好比说日志收集系统，为了不数据在传输过程当中丢失，还有订单系统，下单后，会生成对应的单据，库存的扣减，消费信息的发送，一个下单，产生这么多的消息，都是经过一个操做的触发，而后将其余的消息放入消息队列中，依次产生。再就是不少网站的，秒杀活动之类的，前多少名用户会便宜，都是经过消息队列来实现的。

这些例子，都是经过消息队列，来实现，业务的解耦，最终数据的一致性，广播，错峰流控等等，从而完成业务的逻辑。

3.消息队列产品

1）rabbit-MQ（最初起源于金融系统，用于分布式系统中存储转发消息。OpenStack）
2）Zero-MQ（SaltStack）
3）Kafka（JAVA）
4）redis（key:value数据库，缓存，消息队列）

二.Redis发布消息的两种模式

1.任务队列模式（queuing）

任务队列：顾名思义，就是“传递消息的队列”。与任务队列进行交互的实体有两类，一类是生产者（producer），另外一类则是消费者（consumer）。生产者将须要处理的任务放入任务队列中，而消费者则不断地从任务独立中读入任务信息并执行。

任务队列的好处
1）松耦合。
生产者和消费者只需按照约定的任务描述格式，进行编写代码。
2）易于扩展。
多消费者模式下，消费者能够分布在多个不一样的服务器中，由此下降单台服务器的负载。

2.发布-订阅模式(publish-subscribe)

其实从Pub/Sub的机制来看，它更像是一个广播系统，多个订阅者（Subscriber）能够订阅多个频道（Channel），多个发布者（Publisher）能够往多个频道（Channel）中发布消息。
能够这么简单的理解： 1）Subscriber：收音机，能够收到多个频道，并以队列方式显示 2）Publisher：电台，能够往不一样的FM频道中发消息 3）Channel：不一样频率的FM频道

3.一个发布者多个订阅者模型

以下图所示，能够做为消息队列或者消息管道。
主要应用：通知、公告

4.多个发布者一个订阅者模型

能够将PubSub作成独立的HTTP接口，各应用程序做为Publisher向Channel中发送消息，Subscriber端收到消息后执行相应的业务逻辑，好比写数据库，显示等等。
主要应用：排行榜、投票、计数。


5.多个发布者多个订阅者模型

故名思议，就是能够向不一样的Channel中发送消息，由不一样的Subscriber接收。
主要应用：群聊、聊天。

6.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. 开头的频道( news.it 、 news.global.today 等等)，诸如此类

5）PUNSUBSCRIBE [pattern [pattern ...]]
退订指定的规则, 若是没有参数则会退订全部规则

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

注意：使用发布订阅模式实现的消息队列，当有客户端订阅channel后只能收到后续发布到该频道的消息，以前发送的不会缓存，必须Provider和Consumer同时在线。

订阅单个频道

#第一个窗口
#登陆Redis
[root@db01 ~]# redis-cli -a 123
#在订阅者的服务器上输入订阅zls
127.0.0.1:6379> SUBSCRIBE zls
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "zls"
3) (integer) 1

#第二个窗口
#登陆Redis
[root@db01 ~]# redis-cli -a 123
#在发布者的服务器上输入信息
127.0.0.1:6379> PUBLISH zls "The Nice Boy Like Me."
(integer) 1

#第一个窗口
#在订阅者的服务器上会看到以下信息
1) "message"
2) "zls"
3) "The Nice Boy Like Me."

结果以下:

订阅多个频道

#第一个窗口
#登陆Redis
[root@db01 ~]# redis-cli -a 123
#在订阅者服务器上输入订阅全部频道
127.0.0.1:6379> PSUBSCRIBE *
Reading messages... (press Ctrl-C to quit)
1) "psubscribe"
2) "*"
3) (integer) 1

#第二个窗口
#在发布者服务器上输入多频道信息
127.0.0.1:6379> PUBLISH zls "The Nice Boy Like Me."
(integer) 1
127.0.0.1:6379> PUBLISH bgx "The Ugly Old Man Like Me."
(integer) 1

#第一个窗口
#在订阅者的服务器上会看到以下信息
1) "pmessage"
2) "*"
3) "zls"
4) "The Nice Boy Like Me."


1) "pmessage"
2) "*"
3) "bgx"
4) "The Ugly Old Man Like Me."

结果以下:

7.消息队列系统对比

客户端在执行订阅命令以后进入了订阅状态，只能接收 SUBSCRIBE 、PSUBSCRIBE、 UNSUBSCRIBE 、PUNSUBSCRIBE 四个命令。 开启的订阅客户端，没法收到该频道以前的消息，由于 Redis 不会对发布的消息进行持久化。 和不少专业的消息队列系统（例如Kafka、RocketMQ、RabbitMQ）相比，Redis的发布订阅略显粗糙。

例如:没法实现消息堆积和回溯。但胜在足够简单，若是当前场景能够容忍的这些缺点，也不失为一个不错的选择。