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

时间 2019-11-16

标签消息队列系列相关概念繁體版

原文原文链接

概念

1. 消息队列协议

比较三种最多见和最流行的基于TCP/IP的消息传递协议，并提供每种优点的快速总结：AMQP、MQTT和STOMP，RabbitMQ 3.0版本中支持全部这三个协议-咱们将使用这些协议做为示例并稍后再回来。git

AMQP

AMQP-高级消息队列协议，旨在做为现有专有消息传递中间件的开放替代品。使用AMQP的两个最重要的缘由是可靠性和互操做性。顾名思义，它提供了与消息传递相关的各类功能，包括可靠的排队，基于主题的发布和订阅消息传递，灵活的路由，事务和安全性。AMQP直接以扇出形式，按主题和基于标题交换路由消息。web

如此丰富的功能集能够实现许多细粒度控制。您能够限制对队列的访问，管理其深度等。消息属性，注释和标题等功能使其很是适合各类企业应用程序。该协议旨在提升许多大型公司的可靠性，这些公司依靠消息传递来集成应用程序并在其组织中移动数据。在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代理。websocket

可是，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...