概念
1. 消息队列协议
比较三种最常见和最流行的基于 TCP/IP 的消息传递协议，并提供每种优势的快速总结：AMQP、MQTT 和 STOMP，RabbitMQ 3.0 版本中支持所有这三个协议 - 我们将使用这些协议作为示例并稍后再回来。
AMQP
AMQP- 高级消息队列协议，旨在作为现有专有消息传递中间件的开放替代品。使用 AMQP 的两个最重要的原因是可靠性和互操作性。顾名思义，它提供了与消息传递相关的各种功能，包括可靠的排队，基于主题的发布和订阅消息传递，灵活的路由，事务和安全性。AMQP 直接以扇出形式，按主题和基于标题交换路由消息。
如此丰富的功能集可以实现许多细粒度控制。您可以限制对队列的访问，管理其深度等。消息属性，注释和标题等功能使其非常适合各种企业应用程序。该协议旨在提高许多大型公司的可靠性，这些公司依靠消息传递来集成应用程序并在其组织中移动数据。在 RabbitMQ 的情况下，有许多不同的语言实现和可用的大样本，使其成为构建大规模，可靠，弹性或群集消息传递基础结构的良好选择。
AMQP 是一种二进制有线协议，旨在实现不同供应商之间的互操作性。在其他协议失败的情况下，AMQP 的采用率很高。摩根大通等公司每天使用它来处理 10 亿条消息。NASA 将其用于星云云计算。Google 将其用于复杂的事件处理。以下是一些其他 AMQP 示例和链接：
它被用于世界上最大的生物识别数据库之一印度的 Aadhar 项目 - 拥有 12 亿个身份。
它被用于 Ocean Observatories Initiative– 一种每天收集 8TB 数据的架构。
amqp.org 提供了更多示例和链接。
MQTT
MQTT（消息队列遥测传输）最初有 IBM 普及计算团队的开发的，它们与工业领域的合作伙伴共同开发。在过去的几年中，该协议已经转移到开源社区，随着移动应用程序的开始，其受欢迎程度显着增加，并且正在进入标准组的手中
MQTT 的合集原则和目标比 AMQP 更简单，，更集中 - 它提供了发布和订阅消息（没有队列），专门针对资源受限的设备和低带宽、高延迟网络，例如拨号线路和卫星链路。基本上，它可以在嵌入式是系统中有效使用。
MQTT 对功能更强大的“企业消息传递”代理商的优势之一是其故意低占用空间使其成为当今移动和开发“物联网”风格应用程序的理想选择。事实上，像 Facebook 这样的公司正在将它作为移动应用程序的一部分，因为它具有如此低的功耗，并且网络带宽很小。
一些基于 MQTT 的代理支持数千个并发设备连接。它提供三种服务质量：1）火灾和遗忘 / 不可靠，2）“至少一次”以确保它至少发送一次（但可能被发送超过一次），以及 3）“确切地说一旦”。
MQTT 的优点是简单（只有五种 API 方法），一个紧凑的二进制数据包有效负载（没有消息属性，压缩标头，比基于文本的 HTTP 更简洁），它非常适合简单的推送消息传递方案，如温度更新，股票价格代码，油压供应或移动通知。它对于将机器连接在一起非常有用，例如使用 MQTT 将 Arduino 设备连接到 Web 服务。
STOMP
STOMP（简单 / 流式文本导向消息传递协议）是这三种协议中唯一一种基于文本的协议，使其在覆盖范围方面更类似与 HTTP。与 AMQP 一样，STOMP 提供带有属性的消息（或帧）标头或帧体。这里的设计原则是创建一些简单且可广泛互操作的东西。例如，可以使用想 telnet 客户端这样简单的东西连接到 STOMP 代理。
但是，STOMP 不处理队列和主题。它使用带有“目标”字符串的 SEND 语义。代理必须映射到内容理解的内容，例如主题，队列或交换。消费者然后订阅这些目的地。由于规范中没有强制要求这些目的地，因此，不同的经济人可能会支持不同的目的地风格。因此，在代理之间移植代码并不总是直截了当的。
但是，STOMP 简单而轻便（尽管在线上优点冗长），具有管饭的语言绑定。它还提供了一些事务语义。其中一个最有趣的例子是 RabbitMQ Web Stomp，它允许您通过 websockets 在浏览器中公开消息。这开辟了一些有趣的可能性 – 比如使用所有类型的信息实时更新浏览器，移动应用程序或机器。
2. 消息队列
什么是消息队列？
消息队列是一种异步的服务间通信方式，使用与无服务和微服务架构。消息在被处理和删除之前一直存储在队列上。每条消息仅可被一直为用户处理一次。消息队列可被用于分离重量级处理、缓存或批处理工作以及缓解高峰期工作负载。
在现代云架构中，应用程序被分解为多个规模较小且更易于开发、部署和维护的独立构建模块。消息队列可为这些分布式应用程序提供通信和协调。消息队列可以显著简化分离应用程序的编码，同时提高性能、可靠性和可扩展性。
借助消息队列，系统的不同部分可相互通信并异步执行处理操作。消息队列提供一个临时存储消息的轻量级缓存区，以及允许软件组件连接到队列以发送接受消息的的终端节点。这些消息通常较小，可以是请求、恢复、错误消息或明文消息等。要发送消息时，一个名为“创建器”的组件将消息添加到队列。消息将存储在队列中，直至名为“处理器”的另一组件检索该消息并执行相关操作。
许多创建器和处理器都可以使用队列，但一条信息只能有一盒处理器处理一次。因此，这种消息收发模式通常称为一对一或点对点通信。如果消息需要由多个处理器进行处理，可采用扇出设计模式将消息队列与发布 / 订阅消息收发结合起来。
3. 消息中间件
RabbitMQ
Kafka
RocketMQ
Qpid
Artemis
NSQ
ZeroMQ
4. 发布 / 订阅消息收发
发布 / 订阅消息收发是一种异步的服务间通信方式，适用于无服务和微服务架构。在发布 / 订阅模式下，发布到主题的任何的任何消息都会立即被主题的所有订阅者接受。发布 / 订阅消息收发可用于启用事件驱动架构，或分离应用程序，以提高性能、可靠性和可扩展性。
发布 / 订阅消息收发基础知识
在现代云架构中，应用程序被分解为多个规模较小且易于开发、部署和维护的独立构建块。发布 / 订阅消息收发可以为这些分布式应用程序提供及时事件通知。
发布 / 订阅模式让消息能够异步广播到系统中的不同部分。消息主题与消息队列类似，可以提供一个轻量型机制来广播异步事件通知，还可以提供能让软件组件连接主题以便发送和接受消息的终端节点。在广播消息时，一个叫做“发布者”的组件会将消息推送到主题。与在消息被检索前批量处理消息的消息队列不同的是，消息主题无需或使用极少消息队列即可传输消息，并将消息立即推送给所有订阅者。订阅该主题的所有组件都会收到广播的每一条消息，除非订阅着设置了消息筛选策略。
消息主题的订阅着通常执行不同的功能，并可以同时对消息执行不同的操作。发布者无需知道谁在使用广播的消息而订阅着也无需知道消息来自哪里。这种消息收发模式与消息队列稍有不同，在消息队列中，发送消息的组件通常知道发送目的地。
技术选择
毫不奇怪，考虑到基本消息传递对数据驱动的应用程序的影响，有许多技术支持某种形式的消息队列，发布 – 订阅消息传递或两者兼而有之。
技术，如 Apache 的 ActiveMQ 的，亚马逊 SQS，IBM 的 WebSphere MQ，RabbitMQ 的，和 RocketMQ 最初设计主要是为消息排队的用例。Apache Kafka 和 Google Cloud Pub / Sub 等其他技术主要用于支持发布 – 订阅用例。其他通常较新的解决方案，如 Apache Pulsar，支持 消息队列和 pub-sub 消息传递。
RabbitMQ、Kafka 和 ActiveMQ 都是用于提供异步通信和解耦进程（分离消息的发送者和接受者）的消息传递技术。它们被称为消息队列，消息代理或消息传递工具。RabbitMQ、Kafka 和 ActiveMQ 都具有相同的基本用途。但可以以不同的方式完成工作。Kafka 始终高吞吐量的分布式消息传递系统。RabbitMQ 是基于 AMQP 的可靠消息代理。ActiveMQ 和 Kafka 都是 Apache 产品，都是用 Java 编写的；RabbitMQ 是用 Erlang 编写的。
https://stackshare.io/stackup…