消息队列简介

---

一、消息队列简介

1.概述

消息是指在应用间传送数据，消息可以只包含文本字符串、或者包含嵌入式对象。

消息队列是一种应用程序对应用程序的通信方法。它是是生产者-消费者模型的一个典型的代表，一端往消息

队列中不断地写入消息，而另一端则可以读取队列中的消息。这样发布者和接受者都不知道对方的存在。

消息队列也可以简单理解为：把要传输的数据放在队列中

2.消息获取模式

消费者获取消息时有两种模式，点对点模式和发布订阅模式

（1）点对点模式

点对点模型通常是一个基于拉取或者轮询的消息传递模型，这种模型从队列中请求消息，而不是将消息推送

到客户端。这种模式的特点是一对一，发送到队列的消息被一个且只有一个接受者接收处理，即使有多

个消息监听者也是如此，消息被收到后即可清除

点对点模式的优点是队列发送数据和客户端接收数据的速度是相匹配的，缺点是客户端需要实时监控队列中

是否有消息存在

（2）发布/订阅模式

发布订阅模型是一个基于推送的消息传送模型，该种模型下订阅者有临时订阅者和持久订阅者之分，临时订

阅者只在主动监听主题时才接收消息；而持久订阅者则监听主题的所有消息，即使当前订阅者不可用，

处于离线状态。这种模型的特点是一对多，数据生产后，推送给所有的订阅者

发布/订阅模式的优点是客户端不需要实时监控队列中是否有消息存在，缺点是队列发送数据的速度无法和多

个客户端接收数据的速度是相匹配

二、消息队列作用

• 解耦：客户端与客户端之间或者客户端和服务器 之间不需要直接连接，而是通过中间件来进行连接。而且允许你
  

独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束

• 冗余：消息队列可以对数据进行持久化（本地备份）直到它们已经被处理，这样就规避了数据的丢失。许多消息

队列均采用“插入-获取-删除”的范式，即在把一个消息从队列中删除之前，需要你的系统明确的指出该消息已

经被处理完毕

• 峰值处理：可以组建集群，进而增大消息入队和处理的频率。在访问量剧增的情况下，应用仍然需要继续发挥作

用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的

浪费。消息队列基于它的可扩展性使其本身可以顶住突发的访问压力，而不会因为突发的超负荷的请求而使

系统完全崩溃

• 数据可恢复：当系统的一部分组件失效时，不会影响到整个的系统 。消息队列降低了进程间的耦合度，即使一个

处理消息的进程挂掉，加入队列中的消息仍可在系统恢复后被处理

• 顺序保证：消息队列本来就是排好序的，并且也能够保证数据按照特定的顺序来进行处理

• 缓冲：消息队列可以控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况

• 异步：用户可以将消息放入队列，不立即处理，仅在需要的时候再去处理，有关同步异步等问题请查看此篇博客

三、常用消息队列简介

常见的消息队列有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ等几种

1.Kafka

• 开源消息系统，基于Scala写成

• 完全的分布式消息队列，Kafka对消息保存时根据Topic进行归类；Kafka集群由多个实例组成，

每个实例（Server）称为一个broker

• 集群和消费者均依赖于Zookeeper集群保存一些meta信息，来保证系统的可用性

• 系统在O(1)的系统开销下进行消息持久化

• 可以自动实现负载均衡

2.Pulsar

比Kafka有更大的吞吐量和更低的延迟。在地域复制和多租户方面性能更优越。

3.RabbitMQ

基于Erlang开发的消息队列，本身支持AMQP、XMPP、SMTP、STOMP等协议，实现了Broker架构，消息

在发送给和客户端时先在中心队列排队。同时比较好的支持负载均衡和数据持久化

4.Redis

基于Key-Value对的NoSQL数据库，支持MQ功能，可视为一个轻量级的队列服务来使用

5.ZeroMQ

ZeroMQ号称最快的消息队列系统，专门设计针对大吞吐量的场景，能够实现高级复杂的队列。它本身有一

个独特的非中间件模式，应用程序可以扮演一个消息服务器或者中间件的角色，但是仅提供非持久化性的队列，宕机

时数据将会丢失。

四、消息队列内容摘要

消息队列的种类较多，每种消息队列又有其自身的特点，我们不可能每种都很精通。因此学习的时候可以精

学一个框架，总结出一些共性的特点，达到触类旁通的目的，下图为消息队列共有的内容

此外，对于RabbitMQ、RocketMQ、Kafka、Redis和Pulsar而言，由于应用的比较广泛，因此会有专门的博

客做简单的介绍