消息队列系列一（相关概念）

概念

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

ActiveMQ

ActiveMQ是由Apache出品，ActiveMQ是一个完全支持JMS1.1和JMS1.4规范的JMS Provider实现。它非常快速，只是多种语言的客户端和协议，而且可以非常容易的嵌入到企业的应用环境中，并有许多高级功能。

主要特性

• 服从JMS规范：JMS规范提供了良好的标准和保证，包括：同步或异步的消息分发，一次或仅一次的消息分发，消息接收和订阅等等。遵从JMS规范的好处在于，不论使用什么JMS实现提供者，这些基础特性都是可用的；
• 连接灵活性：ActiveMQ提供了广泛的连接协议，支持的协议有：HTTP/S，IP多播，SSL，TCP，UDP等等。对众多协议的支持让ActiveMQ拥有了很好的灵活性
• 支持的协议种类多：OpenWrite、STOMP、REST、XMMP、AMQP；
• 持久化插件和安全插件：ActiveMQ提供了多种持久化选择。而且，ActiveMQ的安全性也可以完全一句用户需求进行自定义鉴权和授权；
• 支持的客户端语言种类多：除了Java之外，还有C/C++，.NET，Perl，PHP，Python，Ruby；
• 代理集群：多个ActiveMQ代理可以组成一个集群来提供服务；
• 异常简单的管理：ActiveMQ是以开发者思维被设计的。所以，它并不需要专门的管理员，因为它提供了简单有实用的管理特性。又很多方法可以监控ActiveMQ不同层面的数据，包括实用在JConsole或者在ActiveMQ的Web console中使用JMXJMX。通过处理JMX的告警消息，通过使用命令行脚本，甚至可以通过监控各种类型的日志。

部署环境

ActiveMQ 可以运行在 Java 语言所支持的平台之上。使用 ActiveMQ 需要：

• Java JDK
• ActiveMQ 安装包

优点

• 跨平台 (JAVA 编写与平台无关，ActiveMQ 几乎可以运行在任何的 JVM 上)；
• 可以用 JDBC：可以将 数据持久化 到数据库。虽然使用 JDBC 会降低 ActiveMQ 的性能，但是数据库一直都是开发人员最熟悉的存储介质；
• 支持 JMS 规范：支持 JMS 规范提供的 统一接口;
• 支持 自动重连 和 错误重试机制；
• 有安全机制：支持基于 shiro，jaas 等多种 安全配置机制，可以对 Queue/Topic 进行 认证和授权；
• 监控完善：拥有完善的 监控，包括 Web Console，JMX，Shell 命令行，Jolokia 的 RESTful API；
• 界面友善：提供的 Web Console 可以满足大部分情况，还有很多 第三方的组件 可以使用，比如 hawtio；

缺点

• 社区活跃度不及 RabbitMQ 高；
• 根据其他用户反馈，会出莫名其妙的问题，会 丢失消息；
• 目前重心放到 activemq 6.0 产品 Apollo，对 5.x 的维护较少；
• 不适合用于 上千个队列 的应用场景；

RabbitMQ

RabbitMQ 于 2007 年发布，是一个在 AMQP (高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。

主要特性

• 可靠性：提供了多种技术可以让你在 性能 和 可靠性 之间进行 权衡。这些技术包括 持久性机制、投递确认、发布者证实 和 高可用性机制；
• 灵活的路由：消息在到达队列前是通过 交换机 进行 路由 的。RabbitMQ 为典型的路由逻辑提供了 多种内置交换机 类型。如果你有更复杂的路由需求，可以将这些交换机组合起来使用，你甚至可以实现自己的交换机类型，并且当做 RabbitMQ 的 插件 来使用；
• 消息集群：在相同局域网中的多个 RabbitMQ 服务器可以 聚合 在一起，作为一个独立的逻辑代理来使用；
• 队列高可用：队列可以在集群中的机器上 进行镜像，以确保在硬件问题下还保证 消息安全；
• 支持多种协议：支持 多种消息队列协议；
• 支持多种语言：用 Erlang 语言编写，支持只要是你能想到的 所有编程语言；
• 管理界面： RabbitMQ 有一个易用的 用户界面，使得用户可以 监控 和 管理 消息 Broker 的许多方面；
• 跟踪机制：如果 消息异常，RabbitMQ 提供消息跟踪机制，使用者可以找出发生了什么；
• 插件机制：提供了许多 插件，来从多方面进行扩展，也可以编写自己的插件。

部署环境

RabbitMQ 可以运行在 Erlang 语言所支持的平台之上，包括 Solaris，BSD，Linux，MacOSX，TRU64，Windows 等。使用 RabbitMQ 需要：

• ErLang 语言包
• RabbitMQ 安装包

优点

• 由于 Erlang 语言的特性，消息队列性能较好，支持 高并发；
• 健壮、稳定、易用、跨平台、支持 多种语言、文档齐全；
• 有消息 确认机制 和 持久化机制，可靠性高；
• 高度可定制的 路由；
• 管理界面 较丰富，在互联网公司也有较大规模的应用，社区活跃度高。

缺点

• 尽管结合 Erlang 语言本身的并发优势，性能较好，但是不利于做 二次开发和维护；
• 实现了 代理架构，意味着消息在发送到客户端之前可以在 中央节点 上排队。此特性使得 RabbitMQ 易于使用和部署，但是使得其 运行速度较慢，因为中央节点 增加了延迟，消息封装后 也比较大；
• 需要学习比较复杂的接口协议，学习和维护成本较高。

RocketMQ

RocketMQ出自阿里的开源产品，用Java语言实现，在设计时参考了Kafka，并做出了自己的一些改进，消息可靠性上比Kafka更好。RocketMQ在阿里内部被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。

主要特性

• 基于队列模型：具有高性能、高可靠、高实时、分布式等特点；
• Producer、Consumer、队列都支持分布式；
• Producer向一些队列轮流发送消息，队列集合称为Topic。Consumer如果做广播消费，则一个Consumer实例消费这个Topic对应的所有队列；如果做集群消费，则多个Consumer实例平均消费这个Topic对应的队列集合；
• 能够保证严格的消息顺序；
• 提供丰富的消息拉取模式；
• 高效的订阅着水平扩展能力；
• 实时的消息订阅机制；
• 亿级消息堆积能力；
• 较少的外部依赖；

部署环境

RocketMQ可以运行在Java语言所支持的平台之上。使用RocketMQ需要：

• Java JDK
• 安装git、Maven
• RocketMQ安装包

优点

• 单机支持一万以上持久化队列；
• RocketMQ的所有消息都是持久化的，先写入系统PageCache，然后刷盘，可以保证内存与磁盘都有一份数据，而访问时，直接从内存读取。
• 模型简单，接口易用（JMS的接口很多场合并不实用）；
• 性能非常好，可以允许大量堆积消息在Broker中；
• 支持多种消费模式，包括集群消费、广播消费等；
• 各个环节分布式扩展设计，支持主从和高可用；
• 开发度比较活跃，版本更新更快；

缺点

• 支持的客户端语言不多，目前是Java及C++，其中C++还不成熟；
• RocketMQ社区关注度及成熟度也不及前两者；
• 没有Web管理界面，提供了一个CLI管理工具代理查询、管理和诊断各种问题；
• 没有在MQ核心里实现JMS等接口

Kafka

Apache Kafka 是一个 分布式消息发布订阅 系统。它最初由 LinkedIn 公司基于独特的设计实现为一个 分布式的日志提交系统 (a distributed commit log)，之后成为 Apache 项目的一部分。Kafka 性能高效、可扩展良好 并且 可持久化。它的 分区特性，可复制 和 可容错 都是其不错的特性。

主要特性

• 快速持久化：可以在 O(1) 的系统开销下进行 消息持久化；
• 高吞吐：在一台普通的服务器上既可以达到 10W/s 的 吞吐速率；
• 完全的分布式系统：Broker、Producer 和 Consumer 都原生自动支持 分布式，自动实现 负载均衡；
• 支持 同步 和 异步 复制两种 高可用机制；
• 支持 数据批量发送 和 拉取；
• 零拷贝技术(zero-copy)：减少 IO 操作步骤，提高 系统吞吐量；
• 数据迁移、扩容 对用户透明；
• 无需停机 即可扩展机器；
• 其他特性：丰富的 消息拉取模型、高效 订阅者水平扩展、实时的 消息订阅、亿级的 消息堆积能力、定期删除机制；

部署环境

使用 Kafka 需要：

• Java JDK
• Kafka 安装包

优点

• 客户端语言丰富：支持 Java、.Net、PHP、Ruby、Python、Go 等多种语言；
• 高性能：单机写入 TPS 约在 100 万条/秒，消息大小 10 个字节；
• 提供 完全分布式架构，并有 replica 机制，拥有较高的 可用性 和 可靠性，理论上支持 消息无限堆积；
• 支持批量操作；
• 消费者 采用 Pull 方式获取消息。消息有序，通过控制 能够保证所有消息被消费且仅被消费 一次；
• 有优秀的第三方 Kafka Web 管理界面 Kafka-Manager；
• 在 日志领域 比较成熟，被多家公司和多个开源项目使用。

缺点

• Kafka 单机超过 64 个 队列/分区 时，Load 时会发生明显的飙高现象。队列 越多，负载 越高，发送消息 响应时间变长；
• 使用 短轮询方式，实时性 取决于 轮询间隔时间；
• 消费失败 不支持重试；
• 支持 消息顺序，但是 一台代理宕机 后，就会产生 消息乱序；
• 社区更新较慢。

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编写的。

Kafka在于分布式架构，RabbitMQ基于AMQP协议来实现，RocketMQ的思路来源于Kafka，改成了主从结构，在事务性和可靠性方面做成了优化。广泛来说，电商、金融等对事务一致性要求很高的，可以考虑RabbitMQ和RocketMQ，对性能要求高的可考虑Kafka。

https://stackshare.io/stackup...