大家好，我是考100分的小小码，祝大家学习进步，加薪顺利呀。今天说一说mq消息队列介绍_mq消息队列原理,希望您对编程的造诣更进一步.

总文档 :文章目录
Github : github.com/black-ant

开新章了 , 后续会用 4-5 个篇幅 , 来聊一聊 MQ 消息队列 , 也不知道能不能聊清楚 ..

这一篇没有太多的技术深度 , 主要是 MQ 的总览 ,如果能把MQ说清楚 , 这一篇的目的也就达到了

一 . 前言

MQ 的框架有很多 , 很难每个都讲清楚 , 这里只主要说说以下几种 :

RabbitMQ :
Kafka
RocketMQ
TubeMQ
ZeroMQ
ActiveMQ

二 . 架构梳理

2.1 前置知识点 : JMS

JMS 是很多 MQ 框架的基础 , JMS 定义了一组接口和语义，允许 Java 应用程序与其他消息传递实现进行通信 , 它即指明了规范 , 也定义了实现结构 .

JMS 基础 :

JMS 有以下几个重要的作用和目的 :

解决 RPC 系统的紧耦合的问题
使开发异步发送和接收业务数据和事件的业务应用程序变得容易
可以被各种各样的企业消息传递产品轻松有效地支持
相对较低层次的抽象，运行在互补层之下
定义一组接口和语义，允许 Java 应用程序与其他消息传递实现进行通信

JMS 成员组成 :

JMS provider : 实现JMS规范的消息传递系统。
JMS clients : 发送和接收消息的 Java 应用程序
Messages : 用于在 JMS 客户机之间传递信息的对象
Administered objects : 由管理员为使用 JMS 客户机而创建的预配置 JMS 对象

消息传递模型 :

JMS 中定义了2种消息传递的方式

点对点(Queue destination) :

在此模型中，消息从生产者传递到一个使用者。消息被传递到目的地(一个队列) ，然后传递到为该队列注册的消费者之一。虽然任意数量的生产者都可以向队列发送消息，但是每个消息都保证由一个使用者传递和使用。如果没有注册消费者使用消息，队列将保存消息，直到消费者注册使用消息为止

发布/订阅(主题目的地) :

在这个模型中，消息从生产者传递到任意数量的消费者。消息被传递到主题目的地，然后传递到所有主题。此外，任意数量的生产者都可以向主题目的地发送消息，每个消息都可以传递给任意数量的订阅者。如果没有注册使用者，主题目的地将不包含消息，除非它为非活动使用者提供了持久订阅。持久订阅表示在主题目的地注册的使用者，该使用者在消息发送到主题时可以处于非活动状态

JMS 消息组成 :

消息由三部分组成: header、properties 和 body

header :
每条消息都需要消息头，它包含用于路由和标识消息的信息。其中一些字段由 JMS 提供者在生成和传递消息期间自动设置，其他字段由客户机根据消息设置

属性(属性是可选的) :
提供客户端可用于筛选消息的值。它们提供有关数据的附加信息，例如创建数据的进程、创建数据的时间。可以将属性视为头的扩展，并由属性名/值对组成。通过使用属性，客户机可以通过指定作为选择条件的某些值来微调它们对消息的选择

主体(也是可选的)包含要交换的实际数据。JMS 规范定义了 JMS 提供者必须支持的六种类型的消息:

Message : 表示没有消息正文的消息
StreamMessage : 一种消息，其主体包含 Java 基本类型流。它是按顺序编写和读取的
MapMessage : 消息的正文包含一组名称/值对。没有定义条目的顺序
TextMessage : 消息体包含一个Java字符串
ObjectMessage : 消息的主体包含序列化的 Java 对象
BytesMessage : 主体包含未解释字节流的消息

2.2 RabbitMQ

RabbitMq 基于 AMQP(Advanced Message Queuing Protocol，高级消息队列协议)实现 , 他有如下的特点 :

支持许多消息传递协议，如 AMQP、 MQTT、 STOMP，因此也称为混合代理。
支持几种发布-订阅、点对点、请求-回复消息传递技术。
使用了智能 broker/dumb 消费者模型，并致力于一致地向消费者传递消息。
支持 Java、 Ruby、。NET、 PHP 和许多其他语言，并提供了一些插件，可以添加这些插件来扩展用例和集成场景。
提供了同步和异步通信模式。

RabbitMQ 主要概念 :

虚拟主机 : 一个虚拟主机持有一组消息交换机、队列和绑定
消息 : 消息不具名 , 由消息头和消息体组成
绑定 : 交换机需要和队列绑定
信道 : 多路复用连接中的一条独立的双向数据流通道。
交换机 : Exchange用于转发消息，但它不会做存储

ExchangeType

fanout: 会把所有发送到该Exchange的消息路由到所有与它绑定的Queue中
direct : direct类型的Exchange路由规则也很简单，它会把消息路由到那些binding key与routing key完全匹配的Queue
topic : 将消息路由到binding key与routing key相匹配的Queue中 , 同时可以使用通配符 : 比如：“*” 匹配特定位置的任意文本，“.” 把路由键分为了几部分，“#” 匹配所有规则等
headers : 根据消息内容中的header 属性

RabbitMQ 特点 : 1、可靠性（Reliability）
RabbitMQ 使用一些机制来保证可靠性，如持久化、传输确认、发布确认。

2、灵活的路由（Flexible Routing）
在消息进入队列之前，通过 Exchange 来路由消息的。对于典型的路由功能，RabbitMQ 已经提供了一些内置的 Exchange 来实现。针对更复杂的路由功能，可以将多个 Exchange 绑定在一起，也通过插件机制实现自己的 Exchange 。

3、消息集群（Clustering）
多个 RabbitMQ 服务器可以组成一个集群，形成一个逻辑 Broker 。

4、高可用（Highly Available Queues）
队列可以在集群中的机器上进行镜像，使得在部分节点出问题的情况下队列仍然可用。

5、多种协议（Multi-protocol）
RabbitMQ 支持多种消息队列协议，比如 STOMP、MQTT 等等。

6、多语言客户端（Many Clients）
RabbitMQ 几乎支持所有常用语言，比如 Java、.NET、Ruby 等等。

7、管理界面（Management UI）
RabbitMQ 提供了一个易用的用户界面，使得用户可以监控和管理消息 Broker 的许多方面。

8、跟踪机制（Tracing）
如果消息异常，RabbitMQ 提供了消息跟踪机制，使用者可以找出发生了什么。

9、插件机制（Plugin System）
RabbitMQ 提供了许多插件，来从多方面进行扩展，也可以编写自己的插件。

RabbitMQ 流程 :

2.3 Kafka

Apache Kafka 是一种分布式数据存储，经过优化以实时提取和处理流数据。流数据是指由数千个数据源持续生成的数据，通常可同时发送数据记录。流平台需要处理这些持续流入的数据，按照顺序逐步处理。

Kafka 为其用户提供三项主要功能

发布和订阅记录流
按照记录的生成顺序高效地存储记录流
实时处理记录流

Kafak 的成员 :

Producer : 根据 partition 方法，将消息发布到指定的Topic 的 partition 里面。
**kafka 集群 ** 接收到producer 发过来的消息后，将其持久化到硬盘
Consumer : 从 kafka 集群 pull 消息，并且控制获取消息的offset
Topic ： kafka 处理的消息源的不同分类
partition : Topic 物理上的分组，一个Topic 可以分为多个 Partition ，每个 Partition 都是一个有序的队列，partition 每条消息都会分配一个有序的ID（offset）
replicas : Partition 的副本集
leader : replicas 中的角色，producer 和 consumer 只跟Leader 交互
follower : replicas 中的一个角色，从 leader 中复制数据，follower 是Leader 的备选者
Message ： 消息，通信的基本单元，每个 Producer 可以向一个 Topic 发布一些消息
Consumer group : 一个消息可以被多个Group 中的一个 consumer 消费

Kafka 流程 :

Pub Sub 流程:

生产者定期向主题发送消息。
Kafka代理存储为该特定主题配置的分区中的所有消息。它确保消息在分区之间平等共享。如果生产者发送两个消息并且有两个分区，Kafka将在第一分区中存储一个消息，在第二分区中存储第二消息。
消费者订阅特定主题。
一旦消费者订阅主题，Kafka将向消费者提供主题的当前偏移，并且还将偏移保存在Zookeeper系综中。
消费者将定期请求Kafka(如100 Ms)新消息。
一旦Kafka收到来自生产者的消息，它将这些消息转发给消费者。
消费者将收到消息并进行处理。
一旦消息被处理，消费者将向Kafka代理发送确认。
一旦Kafka收到确认，它将偏移更改为新值，并在Zookeeper中更新它。由于偏移在Zookeeper中维护，消费者可以正确地读取下一封邮件，即使在服务器暴力期间。
以上流程将重复，直到消费者停止请求。
消费者可以随时回退/跳到所需的主题偏移量，并阅读所有后续消息。

订阅流程 :

生产者以固定间隔向某个主题发送消息。
Kafka存储在为该特定主题配置的分区中的所有消息，类似于前面的方案。
单个消费者订阅特定主题，假设 Topic-01 为 Group ID 为 Group-1 。
Kafka以与发布 – 订阅消息相同的方式与消费者交互，直到新消费者以相同的组ID 订阅相同主题 Topic-01
一旦新消费者到达，Kafka将其操作切换到共享模式，并在两个消费者之间共享数据。此共享将继续，直到用户数达到为该特定主题配置的分区数。
一旦消费者的数量超过分区的数量，新消费者将不会接收任何进一步的消息，直到现有消费者取消订阅任何一个消费者。出现这种情况是因为Kafka中的每个消费者将被分配至少一个分区，并且一旦所有分区被分配给现有消费者，新消费者将必须等待。

Kafka 整体架构 :

Kafka 对比 RabbitMQ

2.4 RocketMQ

Apache RocketMQ是一个统一的消息传递引擎，轻量级数据处理平台

RocketMQ 成员 :

生产者（Producer）: 负责产生消息，生产者向消息服务器发送由业务应用程序系统生成的消息。
消费者（Consumer）: 负责消费消息，消费者从消息服务器拉取信息并将其输入用户应用程序。
消息服务器（Broker）: 是消息存储中心，主要作用是接收来自 Producer 的消息并存储， Consumer 从这里取得消息。
名称服务器（NameServer）: 用来保存 Broker 相关 Topic 等元信息并给 Producer ，提供 Consumer 查找 Broker 信息。

RocketMQ 流程

1、启动 Namesrv
Namesrv起来后监听端口，等待 Broker、Producer、Consumer 连上来，相当于一个路由控制中心。

2、Broker 启动
Broker 跟所有的 Namesrv 保持长连接，定时发送心跳包。心跳包中，包含当前 Broker 信息(IP+端口等)以及存储所有 Topic 信息。注册成功后，Namesrv 集群中就有 Topic 跟 Broker 的映射关系。

3、收发消息前，先创建 Topic
创建 Topic 时，需要指定该 Topic 要存储在哪些 Broker上。也可以在发送消息时自动创建Topic。

4、Producer 发送消息
启动时，先跟 Namesrv 集群中的其中一台建立长连接，并从Namesrv 中获取当前发送的 Topic 存在哪些 Broker 上，然后跟对应的 Broker 建立长连接，直接向 Broker 发消息。

5、Consumer 消费消息
Consumer 跟 Producer 类似。跟其中一台 Namesrv 建立长连接，获取当前订阅 Topic 存在哪些 Broker 上，然后直接跟 Broker 建立连接通道，开始消费消息。

这张图来自于自身理解 , 不确定有没有问题….

对比其他消息队列 (PS : 来着 RocketMQ 官方)

2.5 ActiveMQ

Apache ActiveMQ 是最流行的开源、多协议、基于 java 的消息服务器。它支持行业标准协议，

Apache ActiveMQ 速度很快，支持许多跨语言客户机和协议，具有易于使用的企业集成模式和许多高级特性，同时完全支持 JMS 1.1和 J2EE 1.4。Apache ActiveMQ 是在 Apache 2.0许可协议下发布的

Apache ActiveMQ 代理是 Java 消息服务(Java Messaging Service，JMS)的实现。JMS 是一种 Java 规范，它允许应用程序以简单和标准的方式在彼此之间来回发送数据。

ActiveMQ 是一个 JMS 提供者。JMS 提供者形成了一个软件框架，用于促进在应用程序中使用 JMS 概念。ActiveMQ 的一个节点允许客户端连接到它并使用这些消息传递概念，这个节点称为“ ActiveMQ Broker”

ActiveMQ 特点 :

1 支持多种跨语言协议 :  Java, C, C++, C#, Ruby, Perl, Python, PHP
2 支持企业集成方案  , 可集成在  在 JMS 客户机和 Message Broker 中
3 支持许多 例如 信息组, 虚拟目的地, 及 综合目的地
4 完全支持 JMS 1.1和 J2EE 1.4，支持瞬态、持久、事务和 XA 消息传递
5 支持 Spring
6 支持常见的 J2EE 服务器
7 支持热插拔
8 支持高性能日志
9 支持高性能集群
10 提供Web API
11 允许 web 浏览器成为消息传递结构的一部分

ActiveMQ 模式 : ActiveMQ 基于 JMS 实现 ,所以它支持 JMS 带来的功能 :

P2P （点对点） 消息域使用 queue 作为 Destination，消息可以被同步或异步的发送和接收，每个消息只会给一个 Consumer 传送一次。

Pub/Sub（发布/订阅，Publish/Subscribe） 消息域使用 topic 作为 Destination，发布者向 topic 发送消息，订阅者注册接收来自 topic 的消息。发送到 topic 的任何消息都将自动传递给所有订阅者。接收方式（同步和异步）与 P2P 域相同。

ActiveMQ 工作方式

一旦消息进入系统，它们就被安排成两种模式: 队列和主题。队列是由代理和客户端生成和使用的消息的 FIFO (先进先出)管道。生产者创建消息并将其推送到这些队列中。然后消费者应用程序轮询和收集这些消息，每次一条消息。主题是基于订阅的消息广播通道。当生产应用程序发送消息时，“订阅”该主题的多个收件人将接收消息的广播。这个生成应用程序在主题消息上下文中有时被称为发布者,

ActiveMQ 流程 :

这里涉及到确认消费的相关逻辑 :

(1)、客户接收消息；
(2)、客户处理消息;
(3)、消息被确认；

总共有四种确认机制 :

Session.AUTO_ACKNOWLEDGE : 客户（消费者）成功从receive方法返回时，或者从MessageListener.onMessage方法成功返回时，会话自动确认消息,然后自动删除消息.

Session.CLIENT_ACKNOWLEDGE : 客户通过显式调用消息的acknowledge方法确认消息,。即在接收端调用message.acknowledge();方法,否则,消息是不会被删除的.

Session. DUPS_OK_ACKNOWLEDGE : 不是必须确认，是一种“懒散的”消息确认，消息可能会重复发送，在第二次重新传送消息时，消息头的JMSRedelivered会被置为true标识当前消息已经传送过一次，客户端需要进行消息的重复处理控制。

Session.SESSION_TRANSACTED : 事务提交并确认。

ActiveMQ 和 Rabbit MQ 对比

基于版本———- > :

ActiveMQ 是一个基于 Java 消息服务客户机的开源消息代理，
RabbitMQ 是在 Advanced Message Queueing 协议上实现的。

工作方式———- > :
RabbitMQ 基于中心工作，这使得它成为一种独特的方法。RabbitMQ 是非常便携和用户友好的。因为负载平衡或持久消息队列等大型操作只在有限的代码行上运行。但是这种方法的可伸缩性较差，速度也较慢，因为其延迟是从中心节点和消息信封的大小添加的。ActiveMQ 更容易实现，并提供了高级特性，如集群、缓存、日志记录和消息存储。

RabbitMQ 嵌入到应用程序中，并充当中途服务。它区分了支持加密、在发生中断时将数据存储在磁盘中作为预先计划、组成集群、重复服务以具有高可靠性。它部署在 OTP 平台上，以确保作为整个系统关键节点的队列的最大可伸缩性和稳定性。

实现方式———- > : ActiveMQ 由 Java 消息服务客户端组成，该客户端能够支持多个客户端或服务器。实现了 RabbitMQ 来设计高级消息队列协议。它被扩展到支持不同的协议，如 MQTT 和 STOMP。

其他优点———- >:
RabbitQ 支持多个消息传递协议，提供确认和消息队列。它可以通过各种语言启用，比如 Python、。和 Java。它还可以让开发人员使用 Chef、 Docker 和 Puppet 等应用程序。它通过开发可能的集群来提供高吞吐量和高可用性。通过可插式身份验证和授权的支持，它可以轻松地处理公共和私有云。HTTP-API 是一个命令行工具，其用户界面有助于管理和监视 RabbitMQ。

ActiveMQ 具有多种优点，可以根据需要应用，效率高。它支持 c，c + + ，。NET 和 Python，可以通过高级消息队列协议嵌入多平台应用程序。它可以通过面向流文本的消息协议 STOMP 在 web 应用程序之间灵活地交换消息。它还编程管理物联网设备。

2.6 ZeroMQ

这个 MQ 就厉害了 ,注意看 , 有很大区别 :

ZeroMQ 基础

ZeroMQ (也称为 ømq、0MQ 或 ZMQ)是一个高性能的异步消息传递库(不是个框架)，旨在用于分布式或并发应用程序。它提供了一个消息队列，但是与面向消息的中间件不同的是，ZeroMQ 系统可以在没有专用消息代理的情况下运行。

需要注意的是 ,Zero MQ 不是一个常规意义上的消息中间件 , 他是传输层 , 是一个库 , 用于实现应用程序和进程之间的消息传递和通信系统——快速和异步 , 他们的目标是成为标准网络协议栈的一部分

ZeroMQ 通过各种传输(TCP、进程内、进程间、多播、 WebSocket 等)支持常见的消息传递模式(pub/sub、 request/reply、 client/server 等) ，使进程间消息传递变得像线程间消息传递一样简单。这使你的代码清晰，模块化，并且极其容易扩展。

很有趣的地方是 , Zero MQ 根据不同的语言提供了不同的实现 , 例如 Java 在 Git 上面就可以找到一个 JZMQ

ZeroMQ 逻辑架构

Sockets : 使用套接字，用户与这些套接字的交互类似于 TCP 套接字，它们之间的区别在于每个套接字都能够处理多个对等通信
Worker Thread : 各种对象驻留在工作线程中每个对象都由一个父对象持有(所有权在图中由一条简单的完整线表示)。许多对象由套接字直接持有; 然而，有一些实例表明实体是由套接字所有的对象控制的
Listener : TCP 侦听器实体侦听传入的 TCP 连接，并为每个新连接生成引擎/会话对象
Session : 它是与 ZeroMQ 套接字通信的会话对象
Engine : 引擎对象与网络通信
Pipe : 当会话与套接字交换消息时。有两个传递消息的方向 Pipe 对象处理要在其中传递的消息的每个方向。实际上，每个管道都是一个无锁队列，用于在线程之间快速传递消息

ZeroMQ 自吹

TCP：ZeroMQ基于消息，使用消息模式而不是字节流。
XMPP：ZeroMQ更简单、快速、更底层。Jabber可建在ØMQ之上。
AMQP：完成相同的工作，ZeroMQ要快100倍，而且不需要代理（规范更简洁——比AMQP的规范文档少278页）
IPC：ZeroMQ可以跨主机通信
CORBA：ZeroMQ不会将复杂到恐怖的消息格式强加于你。
RPC：ZeroMQ完全是异步的，你可以随时增加/删除参与者。
RFC 1149：ZeroMQ比它快多了！
29west LBM：ZeroMQ是自由软件！
IBM Low-latency：ZeroMQ是自由软件！
Tibco：ZeroMQ仍然是自由软件！

ZeroMQ 消息模式

发布订阅

Pull or Push

异步请求响应
ZeroMQ Request.jpg

ZeroMQ 和 RabbitMQ 区别

ZeroMQ 对比 Kafka

2.7 TubeMQ

TubeMQ 是腾讯出品 , 现在已经捐赠给了 Apache , TubeMQ属于万亿级分布式消息中间件，专注于海量数据下的数据传输和存储，在性能、可靠性，和成本方面具有独特的优势 , 官方给出的数据是支持10万亿+的数据访问

TubeMQ 成员架构

Portal: 负责对外交互和运维操作的Portal部分，包括API和Web两块，API对接集群之外的管理系统，Web是在API基础上对日常运维功能做的页面封装；

Master： 负责集群控制的Control部分，该部分由1个或多个Master节点组成，Master HA通过Master节点间心跳保活、实时热备切换完成（这是大家使用TubeMQ的Lib时需要填写对应集群所有Master节点地址的原因），主Master负责管理整个集群的状态、资源调度、权限检查、元数据查询等；

Broker： 负责实际数据存储的Store部分，该部分由相互之间独立的Broker节点组成，每个Broker节点对本节点内的Topic集合进行管理，包括Topic的增、删、改、查，Topic内的消息存储、消费、老化、分区扩容、数据消费的offset记录等，集群对外能力，包括Topic数目、吞吐量、容量等，通过水平扩展Broker节点来完成；

Client： 负责数据生产和消费的Client部分，该部分我们以Lib形式对外提供，大家用得最多的是消费端，相比之前，消费端现支持Push、Pull两种数据拉取模式，数据消费行为支持顺序和过滤消费两种。对于Pull消费模式，支持业务通过客户端重置精确offset以支持业务extractly-once消费，同时，消费端新推出跨集群切换免重启的BidConsumer客户端；

Zookeeper： 负责offset存储的zk部分，该部分功能已弱化到仅做offset的持久化存储，考虑到接下来的多节点副本功能该模块暂时保留。

TubeMQ 特点

纯 Java 实现语言
引入 Master 协调节点：相比 Kafka 依赖于 Zookeeper 完成元数据的管理和实现 HA 保障不同，TubeMQ 系统采用的是自管理的元数据仲裁机制方式进行，Master 节点通过采用内嵌数据库 BDB 完成集群内元数据的存储、更新以及 HA 热切功能，负责 TubeMQ 集群的运行管控和配置管理操作，对外提供接口等；通过 Master 节点，TubeMQ 集群里的 Broker 配置设置、变更及查询实现了完整的自动化闭环管理，减轻了系统维护的复杂度
服务器侧消费负载均衡：TubeMQ 采用的是服务侧负载均衡的方案，而不是客户端侧操作，提升系统的管控能力同时简化客户端实现，更便于均衡算法升级
系统行级锁操作：对于 Broker 消息读写中存在中间状态的并发操作采用行级锁，避免重复问题
Offset 管理调整：Offset 由各个 Broker 独自管理，ZK 只作数据持久化存储用（最初考虑完全去掉ZK依赖，考虑到后续的功能扩展就暂时保留）
消息读取机制的改进：TubeMQ 采用的是消息随机读取模式,同时为了降低消息时延又增加了内存缓存读写,对于带 SSD 设备的机器,增加消息滞后转 SSD 消费的处理，解决消费严重滞后时吞吐量下降以及 SSD 磁盘容量小、刷盘次数有限的问题，使其满足业务快速生产消费的需求
消费者行为管控：支持通过策略实时动态地控制系统接入的消费者行为，包括系统负载高时对特定业务的限流、暂停消费，动态调整数据拉取的频率等；
服务分级管控：针对系统运维、业务特点、机器负载状态的不同需求，系统支持运维通过策略来动态控制不同消费者的消费行为，比如是否有权限消费、消费时延分级保证、消费限流控制，以及数据拉取频率控制等
系统安全管控：根据业务不同的数据服务需要，以及系统运维安全的考虑，TubeMQ 系统增加了 TLS 传输层加密管道，生产和消费服务的认证、授权，以及针对分布式访问控制的访问令牌管理，满足业务和系统运维在系统安全方面的需求
资源利用率提升改进：相比于 Kafka，TubeMQ 采用连接复用模式，减少连接资源消耗；通过逻辑分区构造，减少系统对文件句柄数的占用，通过服务器端过滤模式，减少网络带宽资源使用率；通过剥离对 Zookeeper 的使用，减少 Zookeeper 的强依赖及瓶颈限制
客户端改进：基于业务使用上的便利性以，我们简化了客户端逻辑，使其做到最小的功能集合，我们采用基于响应消息的接收质量统计算法来自动剔出坏的 Broker 节点，基于首次使用时作连接尝试来避免大数据量发送时发送受阻