消息队列(MQ)介绍

1.MQ使用场景

异步通信

有些企业不想也不需要立即处理这些信息。消息队列提供了一种异步处理机制，允许用户将信息放入队列，但不会立即处理。把你想放在队列中的信息，然后在必要时处理它。

解耦

降低工程之间的强依赖性，适应异构系统。在项目启动之初，极难预测项目未来会遇到什么需求。通过在处理过程中间插入一个基于数据的隐含接口层，在处理过程中实现两侧的处理过程。当应用程序发生变化时，只要它们遵守相同的接口约束，就可以独立扩展或修改两侧的处理过程。

冗余

在某些情况下，处理数据的过程会失败。除非数据持久，否则会丢失。消息队列将数据持久化，直到它们完全处理，以避免数据丢失的风险。许多消息队列使用"插入-获取-删除"在范式中，在从队列中删除消息之前，您的处理系统需要明确指出消息已经处理，以确保您的数据安全保存，直到您使用。

扩展性

因为消息队列解耦了你的处理过程，只要增加处理过程，就很容易增加消息进入和处理的频率。无需更改代码或调整参数。便于分布式扩展。

过载保护

当访问量急剧增加时，应用程序仍然需要继续发挥作用，但这种紧急流量无法提取预测；投资资源随时待命无疑是一种巨大的浪费，以应对此类瞬时峰值访问。使用信息队列可以使关键组件承受紧急访问压力，而不会因紧急超载要求而完全崩溃。

可恢复性

当系统的部分组件失效时，不会影响整个系统。消息队列减少了过程之间的耦合，因此即使处理消息的过程被挂断，系统恢复后仍然可以处理添加到队列中的消息。

顺序保证

在大多数使用场景中，数据处理的顺序非常重要。大多数新闻队列最初是排序的，并且可以确保数据按特定的顺序处理。

缓冲

在任何重要的系统中，都会有需要不同处理时间的元素。缓冲有助于控制和优化数据流通过系统的速度，通过缓冲层帮助任务最高效地执行。调整系统响应时间。

数据流处理

分布式系统产生的大量数据流，如业务日志、监控数据、用户行为等，实时或批量收集和总结这些数据流，然后进行大数据分析是当前互联网的必要技术，通过消息队列完成这些数据收集是最好的选择。

2.MQ原理

2.1MQ模型

Pub/Sub发布订阅(广播):使用topic作为通信载体

PTP点对点：使用queue作为通信载体

2.2 MQ的组成

Broker：作为消息服务器server提供核心新闻服务

Producer:新闻制作人、业务发起人负责向生产新闻传递broker

Consumer：负责消息消费者、业务处理方broker获取消息并进行业务逻辑处理

Topic:主题，发布订阅模式下的新闻统一收集地，不同的生产者向topic发短信，由MQ服务器分发给不同的订阅者，实现新闻广播

Queue：队列，PTP在模式下，特定生产者向特定生产queue发送消息，消费者订阅特定信息queue接收指定信息

Message：根据不同通信协议定义的固定格式编码的数据包，包装业务数据，实现消息传输

2.3 MQ常用协议

AMQP

AMQP即Advanced Message Queuing Protocol,提供统一消息服务的应用层标准高级消息队列协议，

是应用层协议设计面向消息的中间件的开放标准。基于本协议的客户端和消息中间件可以传递消息，并且

不受不同产品、不同语言开发等条件的限制。

优点：可靠、通用

MQTT协议

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输IBM开发的即时通信协会

该协议可能成为物联网的重要组成部分。该协议支持几乎所有与外部连接的平台，

例如，它被用作传感器和致动器Twitter让房屋联网)通信协议。

优点：格式简单，占用带宽小，移动通信，PUSH、嵌入式系统

STOMP协议

STOMP（Streaming Text Orientated Message Protocol）流文本定向消息协议是一种MOM(Message Oriented Middleware，简单的文本协议是为新闻中间件设计的。STOMP提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互。

优点:命令模式(非)topic\queue模式）

XMPP协议

XMPP(可场协议可扩展消息处理，Extensible Messaging and Presence Protocol）基于可扩展标记语言（XML）该协议主要用于即时消息（IM）以及在线现场探测。适用于服务器之间的准即时操作。核心是基于XML即使其操作系统与浏览器不同，该协议最终也可能允许因特网用户向因特网其他人发送即时消息。

优点：一般开放，兼容性强，可扩展，安全性高XML编码格式占用带宽大

其他基于TCP/IP自定义协议

一些特殊框架(如:redis、kafka、zeroMq等)根据自己的需要不严格遵MQ以规范为基础TCP\IP通过网络自行包装一套协议socket传输接口，实现MQ的功能。

2.4 MQ选型

RabbitMQ

使用Erlang开源消息队列本身就支持许多协议：AMQP，XMPP, SMTP, STOMP，也正是这样，使其变得非常重量级，更适合企业级发展。同时实现了Broker结构的核心思想是，生产者不会直接向队列发送消息，而是在发送给客户端时在中心队列中排队。对路由(Routing)，负载均衡(Load balance)、数据持久化有很好的支持。多用于企业级ESB整合。

ZeroMQ

又称?MQ、0MQ、ZMQ，被称为最快的新闻队列系统，专门开发高吞吐量、低延迟的场景，常用于金融界的应用，侧重于实时数据通信场景。ZMQ能够实现RabbitMQ不擅长高级/复杂的队列，但开发人员需要组合各种技术框架，开发成本高。因此ZeroMQ独特的非中间件模式更像是一个socket library，您不需要安装和操作消息服务器或中间件，因为您的应用程序本身就是使用ZeroMQ API完成逻辑服务的角色。但是ZeroMQ如果只提供非持久性队列，down机器，数据将丢失。如：Twitter的Storm中使用ZeroMQ传输为数据流。 ZeroMQ套接字是与传输层无关的：ZeroMQ套接字统一定义了所有传输层协议API接口。默认支持 进程内(inproc) ，进程间(IPC) ，多播 ，TCP只要连接字符串的前缀简单地改变，协议就可以在不同的协议之间切换。从进程间的本地通信到分布式通信，可以随时以最低的成本切换到TCP通信。ZeroMQ处理连接建立、断开和重连的逻辑。

特性：

无锁队列模型

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

批量处理算法

对应性优化了批量消息，可以批量接收和发送消息。

多核线程绑定不需要CPU切换

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

ActiveMQ

Apache下一个子项目。使用Java完全支持JMS1.1和J2EE 1.4规范的 JMS Provider少量代码可以有效地实现高级应用场景。支持可插拔传输协议，如：in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。RabbitMQ、ZeroMQ、ActiveMQ支持常用语言客户端 C 、Java、.Net,、Python、 Php、 Ruby等。

Redis

使用C语言开发的一个Key-Value的NoSQL虽然数据库的开发和维护非常活跃，但是是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。

 

Kafka 

Apache下的一个子项目，使用scala实现的一个高性能分布式Publish/Subscribe消息队列系统，具有以下特性： 快速持久化：通过磁盘顺序读写与零拷贝机制，可以在O(1)的系统开销下进行消息持久化； 

高吞吐：在一台普通的服务器上既可以达到10W/s的吞吐速率； 

高堆积：支持topic下消费者较长时间离线，消息堆积量大； 

完全的分布式系统：Broker、Producer、Consumer都原生自动支持分布式，依赖zookeeper自动实现复杂均衡； 

支持Hadoop数据并行加载：对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。