2**)多点广播**：MQ适用于不同类型的应用。其中重要的，也是正在发展中的是"多点广播"应用，即能够将消息发送到多个目标站点(DestinationList)。可以使用一条MQ指令将单一消息发送到多个目标站点，并确保为每一站点可靠地提供信息。MQ不仅提供了多点广播的功能，而且还拥有智能消息分发功能，在将一条消息发送到同一系统上的多个用户时，MQ将消息的一个复制版本和该系统上接收者的名单发送到目标MQ系统。目标MQ系统在本地复制这些消息，并将它们发送到名单上的队列，从而尽可能减少网络的传输量。

3)发布/订阅(Publish/Subscribe)模式：发布/订阅功能使消息的分发可以突破目的队列地理指向的限制，使消息按照特定的主题甚至内容进行分发，用户或应用程序可以根据主题或内容接收到所需要的消息。发布/订阅功能使得发送者和接收者之间的耦合关系变得更为松散，发送者不必关心接收者的目的地址，而接收者也不必关心消息的发送地址，而只是根据消息的主题进行消息的收发。在MQ家族产品中，MQEventBroker是专门用于使用发布/订阅技术进行数据通讯的产品，它支持基于队列和直接基于TCP/IP两种方式的发布和订阅。

4)群集(Cluster)：为了简化点对点通讯模式中的系统配置，MQ提供Cluster(群集)的解决方案。群集类似于一个域(Domain)，群集内部的队列管理器之间通讯时，不需要两两之间建立消息通道，而是采用群集(Cluster)通道与其它成员通讯，从而大大简化了系统配置。此外，群集中的队列管理器之间能够自动进行负载均衡，当某一队列管理器出现故障时，其它队列管理器可以接管它的工作，从而大大提高系统的高可靠性。

为什么使用消息队列

过去几年中，我们一直在使用、构建和宣传消息队列，我们认为它们是很令人敬畏的。我们相信对任何架构或应用来说，消息队列都是一个至关重要的组件，下面是十个理由:

1.1应用解耦

在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息队列在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

1.2 数据冗余

有时在处理数据的时候处理过程会失败。除非数据被持久化，否则将永远丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。在被许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理过程明确的指出该消息已经被处理完毕，确保你的数据被安全的保存直到你使用完毕。

1.3 扩展性

因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的；只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。

1.4 灵活性与流量削峰

当你的应用上了Hacker News的首页，你将发现访问流量攀升到一个不同寻常的水平。在访问量剧增的情况下，你的应用仍然需要继续发挥作用，但是这样的突发流量并不常见；如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住增长的访问压力，而不是因为超出负荷的请求而完全崩溃。

1.5可恢复性

当体系的一部分组件失效，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。而这种允许重试或者延后处理请求的能力通常是造就一个略感不便的用户和一个沮丧透顶的用户之间的区别。

1.6送达保证

消息队列提供的冗余机制保证了消息能被实际的处理，只要一个进程读取了该队列即可。在此基础上，IronMQ提供了一个"只送达一次"保证。无论有多少进程在从队列中领取数据，每一个消息只能被处理一次。这之所以成为可能，是因为获取一个消息只是"预定"了这个消息，暂时把它移出了队列。除非客户端明确的表示已经处理完了这个消息，否则这个消息会被放回队列中去，在一段可配置的时间之后可再次被处理。

1.7排序保证

在许多情况下，数据处理的顺序都很重要。消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。IronMO保证消息浆糊通过FIFO（先进先出）的顺序来处理，因此消息在队列中的位置就是从队列中检索他们的位置。

1.8缓冲

在任何重要的系统中，都会有需要不同的处理时间的元素。例如,加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行–写入队列的处理会尽可能的快速，而不受从队列读的预备处理的约束。该缓冲有助于控制和优化数据流经过系统的速度。

1.9 理解数据流

在一个分布式系统里，要得到一个关于用户操作会用多长时间及其原因的总体印象，是个巨大的挑战。消息系列通过消息被处理的频率，来方便的辅助确定那些表现不佳的处理过程或领域，这些地方的数据流都不够优化。

1.10 异步通信

很多时候，你不想也不需要立即处理消息。消息队列提供了异步处理机制，允许你把一个消息放入队列，但并不立即处理它。你想向队列中放入多少消息就放多少，然后在你乐意的时候再去处理它们。

消息队列应用场景

以下介绍消息队列在实际应用中常用的使用场景。异步处理，应用解耦，流量削锋和消息通讯四个场景。

2.1异步处理

场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种 1.串行的方式；2.并行方式

a、串行方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端。

b、并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间

假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是150毫秒，并行的时间可能是100毫秒。

因为CPU在单位时间内处理的请求数是一定的，假设CPU1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次（1000/150）。并行方式处理的请求量是10次（1000/100）

小结：如以上案例描述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。如何解决这个问题呢？

引入消息队列，将不是必须的业务逻辑异步处理。改造后的架构如下：

按照以上约定，用户的响应时间相当于是注册信息写入数据库的时间，也就是50毫秒。注册邮件，发送短信写入消息队列后，直接返回，因此写入消息队列的速度很快，基本可以忽略，因此用户的响应时间可能是50毫秒。因此架构改变后，系统的吞吐量提高到每秒20 QPS。比串行提高了3倍，比并行提高了两倍。

异步的本质目的：让用户访问操作感知降低到最低

2.2应用解耦

场景说明：用户下单后，订单系统需要通知库存系统。传统的做法是，订单系统调用库存系统的接口。如下图：

传统模式的缺点：假如库存系统无法访问，则订单减库存将失败，从而导致订单失败，订单系统与库存系统耦合

如何解决以上问题呢？引入应用消息队列后的方案，如下图：

订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功

库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作

假如：在下单时库存系统不能正常使用。也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦。

应用解耦的本质目的：让用户下订单的感知降到最低

2.3流量削锋

流量削锋也是消息队列中的常用场景，一般在秒杀或团抢活动中使用广泛。

应用场景：秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。为解决这个问题，一般需要在应用前端加入消息队列。

a、可以控制活动的人数

b、可以缓解短时间内高流量压垮应用

用户的请求，服务器接收后，首先写入消息队列。假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面。

秒杀业务根据消息队列中的请求信息，再做后续处理

秒杀的场景，我们可以举一反三，比如开奖、抽奖、抢购等营销活动。本质目的：让用户感知舒服快速获得结果（不论成功失败），不会出现卡、顿、莫名其妙的异常。

2.4日志处理

日志处理是指将消息队列用在日志处理中，比如Kafka的应用，解决大量日志传输的问题。架构简化如下

日志采集客户端，负责日志数据采集，定时写受写入Kafka队列

Kafka消息队列，负责日志数据的接收，存储和转发

日志处理应用：订阅并消费kafka队列中的日志数据

2.5消息通讯

消息通讯是指，消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯。比如实现点对点消息队列，或者聊天室等

点对点通讯：

客户端A和客户端B使用同一队列，进行消息通讯。客户端A和客户端B使用同一队列，进行消息通讯。

聊天室通讯：

客户端A，客户端B，…客户端N订阅同一主题，进行消息发布和接收。实现类似聊天室效果。客户端A，客户端B，客户端N订阅同一主题，进行消息发布和接收。实现类似聊天室效果。以上实际是消息队列的两种消息模式，点对点或发布订阅模式。模型为示意图，供参考。

消息通讯使用消息队列的一个天然优势就是队列自带排序效果

消息中间件使用范例

3.1电商系统

消息队列采用高可用，可持久化的消息中间件。比如Active MQ，Rabbit MQ，Rocket Mq。

（1）应用将主干逻辑处理完成后，写入消息队列。消息发送是否成功可以开启消息的确认模式。（消息队列返回消息接收成功状态后，应用再返回，这样保障消息的完整性）

（2）扩展业务应用（发短信，配送处理）订阅队列消息。采用推或拉的方式获取消息并处理。

（3）消息将应用解耦的同时，带来了数据一致性问题，可以采用最终一致性方式解决。比如主数据写入数据库，扩展业务应用根据消息队列，并结合数据库方式（注：回表确认）实现基于消息队列的后续处理。

一般用于服务应用解耦，把前置服务应用与后置服务应用（用户不可见或无需实时得知的服务）分离解耦，通过消息中间件承上启下完成上一个服务异步触发后续多个服务，实现逻辑业务解耦

3.2日志收集系统

分为Zookeeper注册中心，日志收集客户端，Kafka集群和Storm集群（OtherApp）四部分组成。

Zookeeper注册中心，提出负载均衡和地址查找服务

日志收集客户端，用于采集应用系统的日志，并将数据推送到kafka队列

Kafka集群：接收，路由，存储，转发等消息处理

Storm集群：与OtherApp处于同一级别，采用拉的方式消费队列中的数据

以下是新浪kafka日志处理应用案例：

(1)Kafka：接收用户日志的消息队列
(2)Logstash：做日志解析，统一成JSON输出给Elasticsearch
(3)Elasticsearch：实时日志分析服务的核心技术，一个schemaless，实时的数据存储服务，通过index组织数据，兼具强大的搜索和统计功能
(4)Kibana：基于Elasticsearch的数据可视化组件，超强的数据可视化能力是众多公司选择ELK stack的重要原因

常用消息队列

4.1 ActiveMQ

ActiveMQ 是Apache出品，最流行的，能力强劲的开源消息总线。ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现，尽管JMS规范出台已经是很久的事情了，但是JMS在当今的J2EE应用中间仍然扮演着特殊的地位。

ActiveMQ特性如下：

多种语言和协议编写客户端。语言: Java,C,C++,C#,Ruby,Perl,Python,PHP。应用协议： OpenWire,Stomp REST,WS Notification,XMPP,AMQP

完全支持JMS1.1和J2EE 1.4规范（持久化，XA消息，事务)

对Spring的支持，ActiveMQ可以很容易内嵌到使用Spring的系统里面去，而且也支持Spring2.0的特性

通过了常见J2EE服务器（如 Geronimo,JBoss 4,GlassFish,WebLogic)的测试，其中通过JCA 1.5 resource adaptors的配置，可以让ActiveMQ可以自动的部署到任何兼容J2EE 1.4 商业服务器上

支持多种传送协议：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA

支持通过JDBC和journal提供高速的消息持久化

从设计上保证了高性能的集群，客户端-服务器，点对点

支持Ajax

支持与Axis的整合

可以很容易得调用内嵌JMS provider，进行测试

4.2 RabbitMQ

RabbitMQ是流行的开源消息队列系统，用erlang语言开发。RabbitMQ是AMQP（高级消息队列协议）的标准实现。支持多种客户端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX，持久化。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。结构图如下：

几个重要概念：

Broker：简单来说就是消息队列服务器实体。
Exchange：消息交换机，它指定消息按什么规则，路由到哪个队列。
Queue：消息队列载体，每个消息都会被投入到一个或多个队列。
Binding：绑定，它的作用就是把exchange和queue按照路由规则绑定起来。
Routing Key：路由关键字，exchange根据这个关键字进行消息投递。
vhost：虚拟主机，一个broker里可以开设多个vhost，用作不同用户的权限分离。
producer：消息生产者，就是投递消息的程序。
consumer：消息消费者，就是接受消息的程序。
channel：消息通道，在客户端的每个连接里，可建立多个channel，每个channel代表一个会话任务。

消息队列的使用过程，如下：

客户端连接到消息队列服务器，打开一个channel。
客户端声明一个exchange，并设置相关属性。
客户端声明一个queue，并设置相关属性。
客户端使用routing key，在exchange和queue之间建立好绑定关系。
客户端投递消息到exchange。

exchange接收到消息后，就根据消息的key和已经设置的binding，进行消息路由，将消息投递到一个或多个队列里。

4.3 ZeroMQ

号称史上最快的消息队列，它实际类似于Socket的一系列接口，他跟Socket的区别是：普通的socket是端到端的（1:1的关系），而ZMQ却是可以N：M 的关系，人们对BSD套接字的了解较多的是点对点的连接，点对点连接需要显式地建立连接、销毁连接、选择协议（TCP/UDP）和处理错误等，而ZMQ屏蔽了这些细节，让你的网络编程更为简单。ZMQ用于node与node间的通信，node可以是主机或者是进程。

引用官方的说法： “ZMQ(以下ZeroMQ简称ZMQ)是一个简单好用的传输层，像框架一样的一个socket library，他使得Socket编程更加简单、简洁和性能更高。是一个消息处理队列库，可在多个线程、内核和主机盒之间弹性伸缩。ZMQ的明确目标是“成为标准网络协议栈的一部分，之后进入Linux内核”。现在还未看到它们的成功。但是，它无疑是极具前景的、并且是人们更加需要的“传统”BSD套接字之上的一层封装。ZMQ让编写高性能网络应用程序极为简单和有趣。”

特点是：

高性能，非持久化
跨平台：支持Linux、Windows、OS X等
多语言支持； C、C++、Java、.NET、Python等30多种开发语言
可单独部署或集成到应用中使用
可作为Socket通信库使用

与RabbitMQ相比，ZMQ并不像是一个传统意义上的消息队列服务器，事实上，它也根本不是一个服务器，更像一个底层的网络通讯库，在Socket API之上做了一层封装，将网络通讯、进程通讯和线程通讯抽象为统一的API接口。支持“Request-Reply “，”Publisher-Subscriber“，”Parallel Pipeline”三种基本模型和扩展模型。

ZeroMQ高性能设计要点：

1、无锁的队列模型

对于跨线程间的交互（用户端和session）之间的数据交换通道pipe，采用无锁的队列算法CAS；在pipe两端注册有异步事件，在读或者写消息到pipe的时，会自动触发读写事件。

2、批量处理的算法

对于传统的消息处理，每个消息在发送和接收的时候，都需要系统的调用，这样对于大量的消息，系统的开销比较大，zeroMQ对于批量的消息，进行了适应性的优化，可以批量的接收和发送消息。

3、多核下的线程绑定，无须CPU切换

区别于传统的多线程并发模式，信号量或者临界区， zeroMQ充分利用多核的优势，每个核绑定运行一个工作者线程，避免多线程之间的CPU切换开销。

4.4 Kafka

Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群机来提供实时的消费。

Kafka是一种高吞吐量的分布式发布订阅消息系统，有如下特性：

通过O(1)的磁盘数据结构提供消息的持久化，这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。（文件追加的方式写入数据，过期的数据定期删除）

高吞吐量：即使是非常普通的硬件Kafka也可以支持每秒数百万的消息

支持通过Kafka服务器和消费机集群来分区消息

支持Hadoop并行数据加载

Kafka相关概念

Broker：Kafka集群包含一个或多个服务器，这种服务器被称为broker[5]

Topic：每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）

Partition：Parition是物理上的概念，每个Topic包含一个或多个Partition.

Producer：负责发布消息到Kafka broker

Consumer：消息消费者，向Kafka broker读取消息的客户端。

Consumer Group：每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。

一般应用在大数据日志处理或对实时性（少量延迟），可靠性（少量丢数据）要求稍低的场景使用。

使用消息队列需要考虑的问题

5.1你也许并不需要消息队列

消息队列是一个能让你获得容错性，分布式，解耦等架构能力的系统。纸上谈兵的话，它看起来还不错。

或许消息列队在你的应用中有不少适用的场景。你可以看下这篇关于消息队列优点的文章，看看到底有哪些合适的场景。但可不要因为说"能解耦那太好了”就轻易使用它。我们来看一个例子——你希望你的邮件发送和订单处理互相解耦。

因此你发送一个消息到消息队列里，然后邮件处理系统取出这个消息并发送邮件。那你在一个独立的单classpath的应用中怎么实现呢？让你的订单处理服务依赖于一个邮件服务，然后调用sendEmail()方法，而不是sendToMQ()方法。如果你使用了消息队列，你需要定义一个两个系统都能识别的消息格式；如果你不使用消息队列，那么你得定义一个方法签名。它们有什么本质的区别吗？其实没有。

不过你可能还有别的消费者想要对某个指定的消息进行额外的处理？这的确是可能发生的，而并不只是针对我们这里说到的这个项目而已。尽管确有可能，但相比添加另一个方法调用而言，它可能并不值当。耦合？是的。不过这个耦合并没有什么不方便的。

那我应该如何处理峰值流量？你可以通过消息队列将请求放到一个持久化队列中，然后再一并处理它们。这是一个非常有用的特性，不过它也受限于几个因素——你的请求是在UI后台处理，还是需要即时响应？serlvet容器的线程池某种程度上可以当作是一个队列，用户最终会拿到响应，但是得需要等待（如果线程的超时时间过短的话，请求可能会丢失）。

你可以使用一个内存队列来存储那些较重的请求（得在UI后台进行处理）。不过注意了，你的队列并不是默认高可用的。比如说，如果一个消息队列节点挂掉了，你的消息就丢失了。因此，不去使用应用节点内的内存队列，而是去使用一个消息队列，这可能并没有什么优势。

消息队列使得我们可以进行异步处理——这的确是个有用的特性。你不希望在用户等待的时候做一些很重的操作。不过你也可以使用一个内存队列，或者简单地启动一个新的线程（比如Spring的@Async注解）。这样又有另一个问题——如果消息丢失的话是否有问题？如果你应用处理请求的节点挂了，你可以进行恢复吗？你会发现这事会经常发生，如果不保证所有消息都处理到的话，很难保证功能的正确性。因此，仅将较重的调用进行异步处理是比较可取的。

把消息放到队列以便让另一个组件来进行处理，对于这个场景，如果消息丢失是无法接受的，这也有一个很简单的解决方案——数据库。你可以把一条processed=false的数据存储到数据库中。然后再运行一个调度作业，将所有未处理的记录挑选出来，异步地进行处理。当处理完成的时候，将标记设为true。我经常用这个方法，包括在一些大型的线上系统中，它也工作得挺好的。

这样你还能不断地对你的应用节点进行扩展，只要它们的内存中没有任何的持久化状态的话。不管你是否使用了消息队列都可以（临时的内存处理队列并不属于持久化状态）。

为什么我要给经常用到的消息队列提供一些备选方案？因为如果你由于不恰当的原因选择了它，那么消息队列可能会成为一个负担。它们并非如想像中那样容易使用。首先，它有一个学习曲线。一般来说，你集成的组件切分得越多，就越容易出现问题。其次，还有一个设置及配置的成本。比如说，当消息队列需要在一个集群中运行的话，比如说多个数据中心，那么这就变得复杂了。

高可用性并不是上来就有的——默认它是不会打开的。还有就是你的应用节点如何连接到消息队列？通过一个刷新的连接池，或者使用短生命周期的DNS记录，还是通过一个负载均衡器？你的队列可能还有许多配置项，大小是多少，行为是怎样的（消费者需不需要确认接受，要不要通知处理失败，多个消费者能够取到同一个消息吗，消息有没有TTL，等等）同时还有网络及消息传递的开销，尤其是现在大家都喜欢用XML或者JSON来传输消息。如果你过度地使用了消息队列，那么它会增加你系统的延时。

最后一点，但并不是最次要的——如果出现问题的话，使用消息队列会让问题跟踪变得异常困难。你没法在IDE中看到所谓的调用层次，因为一旦你发送消息到队列里了，你就得自己去查找它在哪里处理的了。这可不是听起来那么简单的。你看到了吧，它会给你增加许多的复杂性，以及许多需要注意的东西。

通常而言，在某些上下文中，消息队列还是非常有用的。当它们的确适合的话，我也会在项目中使用它们——比方说，我们不想丢失消息，但又希望能快速地进行处理。我也见过它在一些不太常见的场景中使用的情况，比如说只有一个应用节点来进行消费，不管是哪个节点投递过来的消息。你还可以看下stackoverflow上的这个问题。还有一些使用场景就是，或许你的确需要进行多语言间的通信，又或者你的数据流已经过于复杂了，不使用新的消息消费者而是增加新方法调用的话代价会很大。

我想说的是那句老掉牙的真理“杀鸡焉用牛刀”。如果你不是很确定已经没有别的更容易管理和维护的方法，一定要使用消息队列的话，最好不要使用它。不要因为”万一它有用呢“而去用它——只有你确实觉得需要的话再去使用。因为很有可能，就像这里说到的这个项目一样，消息队列其实是没有必要的。

最简单的联系、最简单的逻辑才是最好的，复杂肯定是因为各种联系没有理清楚。先去理清楚场景遇到什么瓶颈？消息队列可以解决这个瓶颈吗？是否大材小用了？是否有可能扩展？是否有备用的简单的其他方案？至少有两个方案的比较，通常是我们出方案的基本原则，除非想了好久都想不出第二个方案。

5.2如何避免消息丢失

选择能够支持消息持久化的MQ方案。如：ActiveMQ、RabbitMQ等，给消息一个处理状态如：process=false。

还可以使用缓存方案做：如Redis，它本身也是支持持久化的。

简单的消息队列，为解决非大量数据的异步处理、应用解耦、流量削峰，我们也可以采用Redis的队列或pub/sub实现，但需要我们自己实现生产与消费代码组件。

参考资料

阅读原文

本文收藏来自互联网，仅用于学习研究，著作权归原作者所有，如有侵权请联系删除

markdown 9ong@TsingChan

部分引用格式为收藏注解，比如本句就是注解，非作者原文。

消息中间件知识汇总

目录

消息队列通讯模式