关于rabbitmq:科普-关于Rabbit-MQ与AMQP协议概念你想了解的都在这里

本文从 AMQP 协定（Advanced Message Queuing Protocol，高级音讯队列协定）、音讯性能、生产模型、金融级用法及其他性能点比照等概念介绍对 RabbitMQ 做了科普，心愿对各位深刻了解 RabbitMQ 有帮忙。

AMQP 协定本身定义了很多概念，上面先对这些概念进行分析，会更偏重从每个概念实体的作用域、职责范畴、从属关系等维度进行介绍。

对应底层一个 AMQP-Client 到 RabbitMQ-Broker 的一个 TCP 连贯。
这边要思考两个端点问题，在 TCP 连贯建设实现后，如下图所示，连贯的指标 Broker 就曾经确定是集群中的一台了，因为是长连贯，除非断连重建，否则对端节点不可变。
所以从这里能够看出 RabbitMQ 相比 Pulsar、RocketMQ 不一样的中央在于，其是一种服务端寻址模型，以 Client 的视角来看，想要连贯任意 Exchange、Queue，只有连上任意一台 Broker 就行。

信道，能够了解为一种逻辑连贯，体现了多路复用的设计思路。
反对串行执行，包含收和发的指令，能够了解为一种半双工模式的“虚构网络通道”。
所有 Exchange、Queue、Binding 的操作都是在 Channel 之上进行的。

等价于一种租户隔离概念，不同 Vhost 下能够创立同名 Exchange、Queue，这样能够进行业务隔离。
RabbitMQ 的权限隔离和权限维度管制的机制是在 Vhost 级别的。
Rabbit 官网原生的全局 Policy 管制在 Vhost 级别。

一个虚构实体，申明不同音讯的路由策略，本身不存储音讯。
一个路由器，基于音讯头部的 RoutingKey 和 Header 将音讯路由到符合条件的具体的 Queue。
反对单播和播送。

音讯存储实体，是音讯底层存储的容器，相似 Pulsar 的 Topic。
单订阅模式，其下的 Consumer 别离生产到一部分音讯。
和存储关联，因而有容量下限、TTL 等存储层的个性。
反对多生产和独占生产, 取决于你订阅时设置的参数。因为它是存储音讯零碎的音讯，所以外部基于一个音讯位点管制长久化生产进度，记录最初被生产并 Ack 的地位。
面向 Consumer。

连接 Exchange 和 Queue 的桥梁，实质是一个规定的申明。
一个 Exchange 下能够有多个 Binding。
一个 Queue 也能够被多个 Binding 关联。
一个 Exchange 到一个 Queue 也能够申明多个 Binding。

上面介绍 RabbitMQ 官网所提供的的开源原生性能，咱们晓得，AMQP 协定能够看做成一种可编程式的音讯队列协定，能够基于其提供的根底模型，通过本人的奇妙搭配组合，结构出多种多样的业务模型。

# publishInfo
exchange: amq.direct
immediate: false
mandatory: false
routingKey: test

# headerBody
bodySize: 1024
properties: 
    - contentType: 
    - encoding: 
    - deliveryMode: 
    - priority: 
    - correlationId: 
    - replyTo: 
    - expiration: 
    - messageId: 
    - timestamp: 
    - type: 
    - userId: 
    - appId: 
    - clusterId: 
    - headers: {}

# contentBody
二进制音讯体 bytes

每个音讯分为三个局部，在网络层面即三个独立数据帧:

PublishInfo: 音讯路由申明信息，能够联想成写电子邮件时填写的指标邮箱、是否接管回执等前置申明。
HeaderBody: 音讯头部，用于存储 RabbitMQ 本身当时定义的申明，能够联想层 HTTP 协定的 Header 一样，此处能够搁置一些对业务通明的上下文信息用于提供某种性能，比方分布式链路追踪的 TraceId。
ContentBody: 音讯体，无差别二进制数据块，服务端不感知其是否压缩、是否加密等，只进行通明的存储和读取投递。

它是一种模型简化，发送音讯时指定 Exchange 为空，RoutingKey 为 QueueName，Broker 当前会间接把这个音讯发送至指标 Queue，这样对用户来说相当于没 Exchange，他认为是间接用 Queue 来生产，就比较简单。
工作队列只实用于单订阅的场景，因为 Queue 只实用于单订阅。

官网解说

Queue 不反对多订阅，通过转换思路实现：

一个 Fanout 类型的 Exchange：相当于多订阅场景的 Topic。
多个不同的 Queue：绑定到该 Exchange，相当于多订阅场景下的 Subscription。
多个 Consumer 生产同一个 Queue：惯例场景多订阅。
每个 Consumer 各自生产一个 Queue：实例级别播送。

官网解说

对齐 RocketMQ、Pulsar 的多订阅生产、播送生产

路由模式是用 Rabbit 最罕用的一种模式。
Producer 公布了一个 Exchange，这个 Exchange 的类型是 Direct，在 Message 中指定 RoutingKey，并设置一个非空的值，接下来申明一些 Queue，这些 Queue 在申明和绑定 Exchange 的时候，须要指定 Binding，音讯在路由的时候判断音讯里的 RoutingKey 和 BindingKey 是不是 equal，如果是对等的就能够路由过去。
相似 tag 过滤的音讯散发场景。

官网解说

对齐 rocketmq、pulsar 的 tag 过滤生产

路由模式的升级版，反对通配符匹配。
Exchange 类型为 Topic。
匹配规定不是正则表达式，是 AMQP 本人的语法。

官网解说

不罕用，匹配规定不基于 RoutingKey，而是基于 HeaderBody.Properties.Headers 中的键值对。
反对齐全匹配所有键值对。
反对只匹配一个键值对。

RPC 模式并不罕用，基于回复队列。
生产者和消费者采纳一问一答的模式。
等价于 RPC 的 request-response 模型。

官网解说

生产模型也是应用一个音讯零碎所须要特地关怀的一环，在业务的应用过程中，更多地会关注一条音讯从生产到投递至消费者整个过程中都经验了什么，整个音讯的申明周期是如何闭环的？

上面次要从 TDMQ RabbitMQ 版的实现来分析 RabbitMQ 协定的音讯生命周期。

已投递未 Ack：Consumer 独占，直到 Consumer 触发 Ack 或者 Consumer 断开。
Ack 音讯：标记已生产，位点后退。
Nack 音讯：底层操作等价于 Ack，会依据配置转发到死信 Exchange，否则抛弃。
Requeue：音讯放回队头，待下次投递。

Queue：负责存储原始音讯数据，按序存储。
RedeliveryTracker：负责记录 Consumer 端 Requeue 的音讯，并触发从新投递，标识投递次数。
Dispatcher：负责管理连贯 Queue 的所有 Consumer，负责音讯的负载平衡、散发、进度治理等。
Limiter：QoS 限流器，基于 Unack 数限流，而不是 QPS，响应上方音讯生命周期。
Unack Tracker：跟踪以后 Channel 中已投递未 Ack 的音讯。

一个 Queue 能够被不同 Connection 连贯、被同一个 Connection 的不同 Channel 连贯。
一个 Channel 中能够启动两个 Consumer 连贯同一个 Queue。
QoS 限流作用域为 Channel，即一个 Channel 中创立的多个 Cconsumer 享有雷同的配额。
如果 BasicQoS Global 设置为 true，那么同一个 Channel 中的 Consumer 用尽配额，该 Channel 下的所有 Consumer 全副阻塞，无奈接管新音讯。
Unack 追踪器也是 Channel 作用域，故一个 Channel 敞开，被该 Channel 独占的所有未 Ack 音讯全副回收到 Queue 级别的跟踪器，进行全局重投递。

basic 指令集: https://www.rabbitmq.com/amqp…

Consumer Prefetch: https://www.rabbitmq.com/cons…

音讯确认：发送反馈，给予 Producer 发送胜利的确认。
备选 Exchange：发送胜利的音讯无奈匹配任何 Binding 的场景。
音讯回退：音讯无奈匹配任何 Binding 时退回到 Producer。
重投递：网络谬误、Consumer 端宕机、业务解决偶发谬误等场景，重试生产复原。
死信 Exchange：业务多次重试、长时间无奈胜利，放入死信，待人工解决或者下一步的自动化修改 or 告警零碎。

通过上述阐明，你应该能利用 RabbitMQ 的性能点，联合本人的业务场景组织一个绝对正当的生产生产拓扑。
除了下面提到的性能点，RabbitMQ 自身还提供了很多其余性能，上面次要列举一部分比照，可供参考和借鉴：

性能点	阐明	TDMQ 反对状况
认证和受权	基于 User/Password 的登录鉴权机制。	整合 Pulsar 本身的 JWT(Role+Token) 机制进行对齐
连贯协商机制	连贯握手协商连贯通信参数。	齐全对齐 RabbitMQ 原生
认证和受权	Vhost 维度配置和 User 的权限关系。	AMQP SDK 应用层面齐全对齐
限流协商机制 (QoS)	基于 Unack 数进行配额限度。	齐全对齐 RabbitMQ 原生

留神：QoS 机制 RabbitMQ 的实现是和规范 AMQP 协定有出入的，咱们抉择对齐 RabbitMQ 而不是 AMQP 标准，咱们也认为 RabbitMQ 的模式较正当，详见 https://www.rabbitmq.com/cons…

性能点	阐明	TDMQ 反对状况
Exchange 绑定 Exchange	RabbitMQ 在 AMQP 协定上的扩大，使 Exchange 不局限于只绑定 Queue，借此能够构建出更加简单的拓扑逻辑。	暂未反对，排期中
死信 Exchange	Queue 的扩大参数，用于 Queue 中抛弃音讯时转发至死信 Exchange。	齐全对齐 RabbitMQ 原生
备选 Exchange	Exchange 的扩大参数，用于音讯发送至 Exchange 时，无奈匹配任何路由规定到上游 Queue，转发至备选 Exchange。	齐全对齐 RabbitMQ 原生

性能点	阐明	TDMQ 反对状况
优先队列	音讯可设置优先级，同时达到的音讯可依据优先级投递，是一种局部性毁坏先入先出机制的性能。	暂未反对，排期中
独占队列	申明队列只能被申明的 Connection 实体所连贯，通常和长期队列配合应用。	暂未反对，排期中
长期队列	随机生成一个长期队列名，可用于以后过程专用，通常配合独占队列和 AutoDelete 一起应用。	暂未反对，排期中
回复队列	用于申明音讯 Producer 解决实现后，向 Producer 进行回包的队列，以此实现一问一答的通信模型。	暂未反对，排期中
TTL	针对音讯设置 TTL(time to live)，过期未投递的音讯将会被抛弃 or 进入死信。	目前反对 Vhost 级别的 TTL 机制
镜像队列	RabbitMQ 为了解决单点贮存问题而引入的，为了实现队列音讯多正本存储。	TDMQ 人造多正本分布式存储，不须要该性能

性能点	阐明	TDMQ 反对状况
音讯确认	音讯在 Broker 胜利存储后，回包 Producer，进行发送胜利确认。	齐全对齐 RabbitMQ 原生
事务音讯	音讯确认性能呈现前的发送确认机制，性能很差，不倡议应用。	暂未反对，待定
提早音讯	音讯发送胜利后，提早肯定工夫后才进行投递。	齐全对齐 RabbitMQ 原生
RPC	基于回复队列封装出的一问一答模型，应用场景较少，倡议用支流 RPC 框架。	暂未反对，待定

RabbitMQ 协定官网文档
RabbitMQ 官网性能介绍
RabbitMQ 协定指令集
RabbitMQ 官网教程
RabbitMQ 官网 Demo

通过这篇文章，心愿能对 RabbitMQ 进行肯定水平的科普，也从一个从 0 到 1 设计一个 RabbitMQ Broker 的开发的角度，浅析了一些 RabbitMQ 的一些生产模型细节，补充点以后网络上对这部分细节的缺漏，可能能够起到一些启发作用。

后续，咱们将会着重分享，咱们如何在 apache pulsar 生态上构建出一套齐全对齐 RabbitMQ 协定的高性能、高可用、云原生音讯队列，相比原生 RabbitMQ，咱们有何劣势，以及咱们在过程中遇到的问题，产生的思考。

敬请期待~

关于rabbitmq:科普-关于Rabbit-MQ与AMQP协议概念你想了解的都在这里

导语

AMQP 协定概念

Connection

Channel

Vhost

Exchange

Queue

Binding

音讯性能

音讯构造

work queue 工作队列

Publish/Subscribe 公布订阅模式

Routing 路由模式

Topic 通配符模式

Header 模式

RPC 模式

生产模型

从音讯的生命周期对待生产模型

从外部外围组件看生产模型

从这张图能够获取那些信息？

金融级用法

性能点比照

通道类

Exchange 类

Queue 类

收发机制类

参考

后记