1. 消息中间件调研

1. 消息中间件概述

一、消息中间件的概念

 消息中间件又叫消息队列（Message Queue），MQ基于队列与消息传递技术，在网络环境中为应用程序提供同步或异步、高效可靠的、与平台无关的消息传输服务，并基于数据通信来进行分布式系统的集成。消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步RPC的主要手段之一。

二、使用消息队列的好处？

• 异步通信：有些业务不想也不需要立即处理消息（例如收集处理日志）。消息队列提供了异步处理机制，允许用户把任意数量的消息放入队列，在需要的时候再去处理它们。将一些操作异步化来减少需要同步进行的操作，进而提升服务的性能。

  异步化有消息队列和线程池两种方案，为什么采用MQ呢？

   微服务思想根据单一职责原则，不同模块负责不同事情，如果把两件事通过线程池揉在一起做，系统见界限就不明显了，做不到完全解耦。扩展：分布式与微服务的关系

• 解耦：交互系统之间没有直接的调用关系，只是通过消息传输，故系统侵入性不强，耦合度低。约束。
• 可扩展性：因为消息队列解耦了不同的操作，所以增大消息入队和处理的频率是很容易的，当应用发生变化时，可以独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
• 过载保护（流量削峰）：使用消息队列能够使关键组件顶住突发的访问压力，可以先将消息积压在队列里，后台慢慢处理，防止服务被打挂。
• 数据流处理：分布式系统产生的海量数据流，如：业务日志、监控数据、用户行为等，针对这些数据流进行实时或批量采集汇总，然后进行大数据分析是当前互联网的必备技术，通过消息队列完成此类数据收集是最好的选择。
• 可恢复性：有些情况下，处理数据的过程会失败。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
• 顺序保证：在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。

三、消息队列的缺点？

• 消息丢失问题： 任何系统不能保证万无一失，比如 Producer 发出了10000条消息，Consumer 只收到了 9999 个消息，万有1失，Consumer 能否接受丢一条？
• 消息重复消费问题：如 Producer 发出了10000条消息，Consumer 只收到了 10001 条消息，有一条是重复的，业务能否接受一条重复的消息，这个是作为系统设计者要考虑的问题。
• 消息的顺序问题：如 Producer 发送顺序是123，Consumer 收到的消息是132，要考虑消费端是否对顺序敏感。
• 数据一致性问题： 如消息丢失问题真的发生且无法找回，会造成两个系统的数据最终不一致，如果消息延迟，会造成短暂不一致。
• 系统可用性降低：引入消息中间件，万一MQ挂了，系统将变得不可用。消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，这将导致系统的复杂度提高。

 针对上面的问题都是消息中间件系统带来的常见困扰，是否需要解决完全依赖业务场景，如果问题对系统产生影响低可以接受，可以忽略，如何解决，每种消息中间件系统设计方案也有所不同，还需要考虑从业务上解决，如消息重复问题，如果 Consumer 不能接受重复消息，那 Consumer 的接口可以设计成“幂等”，这样就不怕重复消息给系统造成影响。

四、消息中间件的组成

• Broker：消息服务器，作为Server提供消息核心服务。
• Producer：消息生产者，业务的发起方，负责生产消息传输给broker。
• Consumer：消息消费者，业务的处理方，负责从broker获取消息并进行业务逻辑处理。
• Topic：主题，发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器分发到不同的订阅者，实现消息的广播。
• Queue：队列，PTP（点对点）模式下，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定消息的接收。
• Message：消息体，根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输。

2. JMS规范

 消息中间件是遵守JMS（java message service）规范的一种软件（少数消息中间件不遵守JMS规范，如Kafka）。

2.1 消息模式

2.1.1 点对点模式

 消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。消息被消费以后，queue中不再存储，所以消息消费者不可能消费到已经被消费的消息。 Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。queue会按照消息服务器将消息放入队列中的顺序把消息传送给消费者，当消息已被消费后，就会从队首将它们删除（除非使用了消息优先级）。消费者在成功接收消息之后需向队列应答成功。

2.1.2 发布订阅模式

 消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。

特点：

1. 每个消息可以有多个消费者。
2. 消息被推送给消费者。这意味着消息会传送给消费者，而无须请求。
3. 发布者通常不会知道哪一个订阅者正在接收主题消息。
4. 每条消息都会传送给称为订阅者的多个消息消费者。订阅者有许多类型，包括持久型、非持久型和动态型。
5. 发布者和订阅者之间有时间上的依赖性。针对某个主题的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息，而且为了消费消息，订阅者必须保持运行的状态。
6. 为了缓和这样严格的时间相关性，JMS允许订阅者创建一个可持久化的订阅。这样，即使订阅者没有被激活（运行），它也能接收到发布者的消息。

2.2 消费方式

1. 同步

 订阅者或消费者调用receive方法来接收消息，receive方法在能够接收到消息之前（或超时之前）将一直阻塞。

2. 异步

 订阅者或消费者可以注册为一个消息监听器。当消息到达之后，系统自动调用监听器的onMessage方法。

2.3 JMS规范接口

参考链接

3. 消息中间件协议

3.1 AMQP协议

 AMQP（Advanced Message Queuing Protocol）高级消息队列协议，一个提供统一消息服务的应用层标准协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件的限制。

优点：可靠、通用。

部分相关产品：

• RabbitMQ

 一个独立的开源实现，服务器端用Erlang语言编写，支持多种客户端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。RabbitMQ发布在Ubuntu、FreeBSD平台。

• OpenAMQ

 AMQP的开源实现，用C语言编写，运行于Linux、AIX、Solaris、Windows、OpenVMS。

• Apache Qpid

 Apache的开源项目，支持C++、Ruby、Java、JMS、Python和.NET。

• Zyre

 一个Broker，实现了RestMS协议和AMQP协议，提供了RESTful HTTP访问网络AMQP的能力。

3.2 MQTT协议

 MQTT（Message Queuing Telemetry Transport）消息队列遥测传输，是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。

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

3.3 STOMP协议

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

优点：命令模式（非topic/queue模式）

部分相关产品：

 ActiveMQ

3.4 XMPP协议

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

优点：通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大

3.5 基于TCP/IP自定义协议

 有些特殊框架（如：Redis、Kafka、ZeroMQ等）根据自身需要未严格遵循MQ规范，而是基于TCP/IP自行封装了一套协议，通过网络socket接口进行传输，实现了MQ的功能。

4. 种MQ对比