本章节主要介绍如何查看分布式消息服务RabbitMQ的监控数据。 操作场景 云监控对RabbitMQ实例的运行状态进行日常监控，可以通过控制台直观的查看RabbitMQ实例各项监控指标。 前提条件 已创建RabbitMQ专享版实例，且实例中有可消费的消息。 操作步骤 1. 登录管理控制台。 2. 在管理控制台右上角单击，选择区域。 说明 此处请选择与您的应用服务相同的区域。 3. 在管理控制台左上角单击，选择“企业中间件”>“分布式消息服务”>“RabbitMQ专享版”，进入分布式消息服务RabbitMQ专享版页面。 4. 通过以下任意一种方法，查看监控数据。 在RabbitMQ实例名称后，单击“查看监控数据”。跳转到云监控页面，查看实例、节点和队列的监控数据，数据更新周期为1分钟。 单击RabbitMQ实例名称，进入实例详情页。在左侧导航栏单击“监控”，进入监控页面，查看实例、节点和队列的监控数据，数据更新周期为1分钟。 在“队列”的监控页面中，如果队列在默认Vhost下，会直接显示队列名。如果队列不在默认Vhost下，队列名称显示为：队列所在的Vhost名称队列名。例如：队列test01在Vhost13142708中，此时监控中显示的队列名为“Vhost13142708test01”。 图1 队列的监控页面

本文主要介绍分布式消息服务RabbitMQ的产品优势。 天翼云分布式消息服务RabbitMQ完全兼容开源社区版本，旨在为用户提供便捷高效的消息队列。业务无需改动即可快速迁移上云，为您节省维护和使用成本。 一键式部署，免去集群搭建烦恼 专享实例只需要在实例管理界面选好规格配置，提交订单，后台将自动创建部署完成一整套RabbitMQ实例。 兼容开源，业务零改动迁移上云 兼容社区版RabbitMQ的API，具备原生RabbitMQ的所有消息处理特性。 业务系统基于开源的RabbitMQ进行开发，只需加入少量认证安全配置，即可使用天翼云分布式消息服务RabbitMQ，做到无缝迁移。 说明 RabbitMQ实例兼容开源社区RabbitMQ 3.8.35版本。 独占式体验 RabbitMQ实例采用物理隔离的方式部署，租户独占RabbitMQ实例，每个RabbitMQ之间互不影响。 高性能 单队列性能最高可达10万TPS（默认配置），增加队列可获得更高性能。 数据安全 独有的安全加固体系，提供业务操作云端审计，消息存储加密等有效安全措施。 在网络通信方面，除了提供SASL认证，还借助虚拟私有云（VPC）和安全组等加强网络访问控制。 无忧运维 天翼云提供一整套完整的监控告警等运维服务，故障自动发现和告警，避免724小时人工值守。RabbitMQ专享实例自动上报相关监控指标，如分区数、主题数、堆积消息数等，并支持配置监控数据发送规则，您可以在第一时间通过短信、邮件等获得业务消息队列的运行使用和负载状态。

说明 分布式消息RabbitMQ旧资费产品根据实例规格分为基础版和高级版，存储空间按照不同类型收费。 旧资费产品目前在 芜湖2、南京3、上海7、重庆2、北京5 资源池开放订购。 包周期 RabbitMQ当前支持包年/包月的计费方式。且按天翼云的包年订购优惠策略享受相关的一次性包年订购优惠。 RabbitMQ队列实例价格如下： 实例类型 实例规格 节点数量 标准资费(元/月) 基础版（300G） 4C8G 3 3248 高级版（300G） 8C16G 3 6321 其中，RabbitMQ队列额外存储空间价格如下： 存储类型 标准资费（元/100GB/月） 普通IO 30 按需计费 RabbitMQ当前支持按需的计费方式，计费颗粒度为按小时。 RabbitMQ队列实例价格如下： 实例类型 实例规格 节点数量 标准资费(元/小时) 基础版（300G） 4C8G 3 6.73 高级版（300G） 8C16G 3 13.13 其中，RabbitMQ队列额外存储空间价格如下： 存储类型 标准资费（元/100GB/小时） 普通IO 0.05

介绍分布式消息服务RabbitMQ监控指标详情。 监控项 分布式消息服务RabbitMQ 版监控指标支持以下监控项： 资源类型 监控项 单位 指标名 维度 实例 每秒消息流入数 个/秒 publishRate 实例 实例 每秒消息流出数 个/秒 deliverRate 实例 实例 消费者数量 个 consumers 实例 实例 连接数量 个 connections 实例 实例 通道数量 个 channels 实例 虚拟主机 每秒消息流入数 个/秒 publishRate 实例、虚拟主机 虚拟主机 每秒消息流出数 个/秒 deliverRate 实例、虚拟主机 虚拟主机 消费者数量 个 consumers 实例、虚拟主机 虚拟主机 连接数量 个 connections 实例、虚拟主机 虚拟主机 通道数量 个 channels 实例、虚拟主机 队列 每秒消息流入数 个/秒 publishRate 实例、虚拟主机、队列 队列 每秒消息流出数 个/秒 deliverRate 实例、虚拟主机、队列 队列 消费者数量 个 consumers 实例、虚拟主机、队列 队列 消息堆积量 个 messages 实例、虚拟主机、队列 交换器 每秒消息流入数 个/秒 publishRate 实例、虚拟主机、交换器 交换器 每秒消息流出数 个/秒 deliverRate 实例、虚拟主机、交换器

本节介绍了分布式消息服务RabbitMQ产品的实例规格。 （一）以下规格选型适用于14个节点 华东1、华北2、西南1、华南2、上海36、青岛20、长沙42、南昌5、武汉41、杭州7、西南2贵州、太原4、郑州5、西安7、呼和浩特3 注意 通用型规格已调整为白名单特性，如需了解该规格参数请联系技术支持。 云原生引擎已调整为白名单特性，如需了解该引擎请联系技术支持。 单机版实例面向用户体验和业务测试场景，无法保证性能和高可用。如果需要在生产环境使用RabbitMQ实例，建议购买集群版实例。 TPS参考值，是指以2K大小的消息为例的每秒处理消息条数，测试场景为不开启持久化的非镜像队列，实时生产实时消费，队列无积压。此数据仅供参考，在实际业务中，队列数、消息堆积、连接数、channel、消费者数、镜像队列、优先级队列、消息持久化和exchange类型等因素会对TPS造成较大影响，不一定能够达到上述性能。 1、RabbitMQ实例规格 RabbitMQ兼容开源RabbitMQ 3.8版本，提供集群和单机两种部署架构实例，支持X86和ARM计算，主机类型为Intel、海光和鲲鹏计算增强型，节点可选择3节点、5节点、7节点、9节点。 存储类型可选择高IO（SAS）、超高IO（SSD），默认选择超高IO。 2、目前所有的可选规格如下：

RabbitMQ触发器可以订阅分布式消息服务RabbitMQ并根据消息触发关联的函数，借此能力，使得函数可以消费指定Queue的消息，执行自定义处理逻辑。 前提条件 已创建函数。 已创建RabbitMQ实例 操作步骤 1. 登录函数计算控制台，点击目标函数，进入函数详情。 2. 选择详情下顶部的配置选项卡。 3. 在配置选项卡中，选择左边的触发器选项卡。 4. 点击创建触发器 ，在弹出的右抽屉中选择RabbitMQ触发器，配置参数解释如下: 配置项 操作 示例 触发器类型 选择RabbitMQ触发器。 RabbitMQ触发器 名称 填写自定义的触发器名称。 rabbitmqtrigger 版本或别名 默认值为LATEST，支持选择任意函数版本或函数别名。 LATEST RabbitMQ实例 选择已创建的RabbitMQ实例。 Vhost 选择订阅的目标虚拟主机。 / Queue 选择订阅的目标队列。 myqueue 调用方法 选择函数调用方式。 同步调用 ：指触发器消费消息后投递到函数是同步调用，会等待函数响应后继续下一个消息投递。 异步调用：指触发器消费消息后投递到函数是异步调用，不会等待函数响应，可以快速消费事件。 User name 访问分布式消息服务RabbitMQ 版服务端时，需要传入用户名和密码进行权限认证，认证通过才允许访问服务端。 Password 访问分布式消息服务RabbitMQ 版服务端时，需要传入用户名和密码进行权限认证，认证通过才允许访问服务端。 触发器启用状态 创建触发器后是否立即启用。默认选择开启，即创建触发器后立即启用触发器。 启用 推送配置 批量推送条数：批量推送的最大值，积压值达到后立刻推送，取值范围为 [1, 10000]。 批量推送间隔：批量推送的最大时间间隔，达到后立刻推送，单位秒，取值[0,15]。默认0无需等待，数据直接推送。 推送格式：函数收到的事件格式，详情请查阅触发器事件消息格式。 重试策略 消息推送函数失败后重试的策略，共两种： 指数退避：指数退避重试，重试5次，重试周期为2，4，8，16，32（秒）。 线性退避：线性退避重试，重试5次，重试周期为1，2，3，4，5（秒）。 容错策略 当重试次数耗尽后仍然失败时的处理方式： 允许容错：当异常发生并超过重试策略配置时直接丢弃。 禁止容错：当异常发生并超过重试策略配置时继续阻塞执行。 死信队列 当容错策略为：允许容错时，可以额外开启死信队列。当开启死信队列时且异常发生并超过重试策略配置时，消息会被投递到指定的消息队列里，当前只支持投递到kafka和rocketmq 注意 请确保使用的用户名已经对选择的虚拟主机授权。

介绍分布式消息服务RabbitMQ连接实例操作内容。 场景描述 连接RabbitMQ实例的场景包括： 1. 消息队列通信：连接RabbitMQ实例可以用于构建分布式系统中的消息队列通信。不同的应用程序或服务可以通过RabbitMQ实例发送和接收消息，实现解耦和异步通信。 2. 任务队列：连接RabbitMQ实例可以用于构建任务队列，将任务提交到RabbitMQ中，然后由消费者从队列中获取任务并进行处理。这样可以实现任务的分发和负载均衡，提高系统的处理能力和可伸缩性。 3. 发布/订阅模式：连接RabbitMQ实例可以用于实现发布/订阅模式，其中发布者将消息发布到交换器，然后订阅者可以从交换器中订阅感兴趣的消息。这样可以实现消息的广播和多个消费者的并行处理。 4. 日志收集：连接RabbitMQ实例可以用于实现日志收集系统，应用程序可以将日志消息发送到RabbitMQ中，然后由日志消费者从队列中获取日志消息并进行处理和存储。 5. 系统集成：连接RabbitMQ实例可以用于实现不同系统之间的集成，通过将消息发送到RabbitMQ中，其他系统可以从队列中获取消息并进行处理，实现系统之间的数据交换和通信。 总之，连接RabbitMQ实例可以应用于各种场景，包括消息队列通信、任务队列、发布/订阅模式、日志收集和系统集成，提供了一种可靠和灵活的消息传递机制。 操作步骤 RabbitMQ是一个开源的消息队列中间件，支持生产者和消费者之间的异步通信。在上述资源准备完成后，接下来需要编译工程生产消费，主要分以下几个步骤： 1、编写生产者代码：使用编程语言编写一个生产者程序。该程序将连接到RabbitMQ服务器，并将消息发送到队列中。 2、编写消费者代码：同样使用编程语言编写一个消费者程序。该程序将连接到RabbitMQ服务器，并从队列中接收消息。 3、运行生产者和消费者：运行生产者程序，它将发送消息到队列中。然后运行消费者程序，它将从队列中接收并处理消息。 4、验证结果：检查生产者和消费者程序的输出，确保消息被正确发送和接收。

本文主要介绍分布式消息服务RabbitMQ的相关概念。 天翼云分布式消息服务RabbitMQ作为消息引擎，RabbitMQ是一个生产者和消费者模型，主要负责接收、存储和转发消息。以下概念基于RabbitMQ进行描述。 消息 消息一般分为两部分，消息体和标签，标签主要用来描述这条消息，消息体是消息的内容，是一个JSON体或者数据等。 生产者发送消息，消费者消费消息，生产者与消费者彼此并无直接关系。 生产者（Producer） 即向队列发送消息的一方。发布消息的最终目的在于将消息内容传递给其他系统/模块，使对方按照约定处理该消息。 消费者（Consumer） 接收消息的一方。消费者订阅RabbitMQ的队列，当消费者消费一条消息时，只是消费消息的消息体。在消息路由的过程中，会丢弃标签，存入到队列中的只有消息体。 队列（Queue） 队列是用于存储消息的，生产者将消息送到队列，消费者从队列中获取和消费消息。多个消费者可以同时订阅同一个队列，队列里的消息分配给不同的消费者。 代理（Broker） 消息中间件的服务节点。

队列监控指标 表3 队列支持的监控指标 指标ID 指标名称 指标含义 取值范围 测量对象 监控周期（原始指标） queuemessagesunacknowledged 队列未确认消息数 该指标用于统计队列中已消费未确认消息数。单位：Count 0~10000000 RabbitMQ实例队列 1分钟 queuemessagesready 队列可消费消息数 该指标用于统计队列中可消费的消息数。单位：Count 0~10000000 RabbitMQ实例队列 1分钟 queueconsumers 消费者数量 该指标用于统计订阅该队列的消费者个数。单位：Count > 0 RabbitMQ实例队列 1分钟 queuemessagespublishrate 生产速率 该指标用于统计每秒该队列的消息流入数。单位：Count/s > 0 RabbitMQ实例队列 1分钟 queuemessagesackrate 消费速率（手工确认） 该指标用于统计该队列每秒传递给客户端并确认的消息数。单位：Count/s > 0 RabbitMQ实例队列 1分钟 queuemessagesdelivergetrate 消费速率 该指标用于统计该队列每秒的消息流出数。单位：Count/s > 0 RabbitMQ实例队列 1分钟 queuemessagesredeliverrate 重传速率 该指标用于统计该队列每秒的重传消息数。单位：Count/s > 0 RabbitMQ实例队列 1分钟 queuemessagespersistent 消息总数（持久化） 该指标用来统计该队列中持久消息的总数（对于瞬时队列始终为0）。单位：Count > 0 RabbitMQ实例队列 1分钟 queuemessagesram 消息总数（内存） 该指标用于统计该队列中驻留在内存中的消息总数。单位：Count > 0 RabbitMQ实例队列 1分钟 queuememory Erlang进程消耗字节数 该指标用于统计与队列关联的Erlang进程消耗的内存字节数，包括堆栈、堆和内部结构。单位：Byte > 0 RabbitMQ实例队列 1分钟 queuemessagebytes 消息大小总和 该指标用于统计该队列中所有消息的大小总和（字节）。单位：Byte > 0 RabbitMQ实例队列 1分钟

本节介绍了分布式消息服务RabbitMQ的定义和主要产品优势。 分布式消息服务RabbitMQ是基于高可用、分布式集群技术，完全兼容RabbitMQ开源社区，支持消息路由、事务消息、优先级队列、延迟队列、死信队列、镜像队列等功能的消息云服务。用户可开箱即用，无需部署免运维，从而实现快速上云。 产品示意图 分布式消息服务RabbitMQ发布订阅基本流程如下： 1、生产者生产的消息，通过TCP连接的信道首先发布到指定的交换机上； 2、交换机通过路由键(RoutingKey)的匹配，选择对应的队列进行投递； 3、消费者订阅队列，消费队列的消息。 核心概念 对照产品示意图，分布式消息服务RabbitMQ的核心概念如下： Producer：消息生产者，即消息的发布方, 生产者生产的消息，首先发布到指定的交换机上，交换机通过路由键(RoutingKey)的匹配，选择对应的队列进行投递。消费者订阅队列，消费队列的消息。 Connection：客户端与Broker间的TCP连接。 Channel：信道，每个连接采用多路复用，包含多个信道。Producer与Broker间采用信道传递数据。 Broker：RabbitMQ服务节点，集群由多个节点组成。 Vhost：虚拟机，一个节点下包含多个Vhost，Vhost间的Exchange，Queue相互隔离。就好比一台物理机上(Broker)部署多台虚拟机(Vhost)，虚拟机采用不同的用户名密码登录，实现多租户。 Exchange：交换机，消息首先会传递到交换机，由交换机匹配路由键(RoutingKey)决定投递到哪个Queue。 Queue：队列，存储消息的数据结构。类比小区的快递柜。 Binding：绑定，交换机与队列间通过路由键(RoutingKey)进行绑定起来。 Consumer，消费者，即消息的接受方。 更多信息请参见名词解释。

本章节主要介绍消息类问题的解决方法。 RabbitMQ实例支持延时消息队列么？ RabbitMQ可以通过设置消息的有效期和死信队列来实现延迟消息。同时，也提供安装插件实现延迟消息。当前RabbitMQ支持的插件：rabbitmqamqp10、rabbitmqdelayedmessageexchange、rabbitmqfederation、rabbitmqsharding、rabbitmqshovel、rabbitmqtracing、rabbitmqmqtt、rabbitmqwebmqtt、rabbitmqstomp、rabbitmqwebstomp和rabbitmqconsistenthashexchange。 消息的最长保留时间是多久？ 一般情况下消息如果未被消费会一直保留，只有被消费后，才会被删除。但是如果设置了过期时间（TTL），则以TTL时间为准。 消息创建时间在哪设置？ 消息创建时间是由生产客户端在生产消息时设置的。 RabbitMQ生产消息的最大长度是多少？ 单条消息的最大长度为50MB，请勿发送大于此长度的消息，否则会导致生产失败。

本章节主要介绍分布式消息服务RabbitMQ的仲裁队列特性。 使用场景 仲裁队列（Quorum Queues）提供队列复制的能力，保障数据的高可用和安全性。使用仲裁队列可以在RabbitMQ节点间进行队列数据的复制，在一个节点宕机时，队列依旧可以正常运行。 仲裁队列适用于队列长时间存在，对队列容错和数据安全要求高，对延迟和队列特性要求相对低的场景。在可能出现消息大量堆积的场景，不推荐使用仲裁队列，因为仲裁队列的写入放大会造成成倍的磁盘占用。 仲裁队列的消息会优先保存在内存中，使用仲裁队列时，建议定义队列最大长度和最大内存占用，在消息堆积超过阈值时从内存转移到磁盘，以免造成内存高水位。 更多关于仲裁队列的说明，请参考Quorum Queues。 说明 分布式消息服务RabbitMQ3.8.35版本才提供仲裁队列特性。 仲裁队列与镜像队列的差异 仲裁队列是RabbitMQ 3.8版本引入的队列类型，它与镜像队列拥有类似的功能，为RabbitMQ提供高可用的队列。镜像队列有一些设计上的缺陷，这也是RabbitMQ提供仲裁队列的原因。 镜像队列主要的缺陷在于消息同步的性能低。 镜像队列包含一个主队列和多个从队列，当生产者向主队列发送一条消息，主队列会将消息同步给从队列，所有的从队列都保存消息后，主队列才会向生产者发送确认。 RabbitMQ使用集群部署时，如果其中一个节点故障下线，待它消除故障重新上线后，它保存的所有从队列的数据都会丢失。此时运维人员需要选择是否同步主队列的数据到从队列中，如果不同步数据，会增加消息丢失的风险。如果同步数据，同步时队列是阻塞的，无法对其进行操作。当队列中存在大量堆积消息时，同步会导致队列几分钟、几小时或者更长时间不可用。 仲裁队列解决了镜像队列的性能和同步问题。 仲裁队列的算法是基于Raft共识算法的一个变种，提供更好的消息吞吐量。仲裁队列包含一个主副本和多个从副本，当生产者向主副本发送一条消息，主副本会将消息同步给从副本，超过半数的副本保存消息后，主副本才会向生产者发送确认。这意味着少部分比较慢的从副本不会影响整个队列的性能。同样地，主副本的选举也需要超过半数的副本同意，这会避免出现网络分区时，队列存在2个主副本。由此可见，仲裁队列相对于可用性更看重一致性。 RabbitMQ使用集群部署时，如果其中一个节点故障下线，待它消除故障重新上线后，它保存的数据不会丢失，主副本会直接从从副本中断的地方开始复制消息。复制的过程是非阻塞的，整个队列不会因为新的副本加入而受到影响。 仲裁队列相比镜像队列，缺少了一些特性，如表1所示，且消耗更多的内存和磁盘。 表1 特性列表 特性 镜像队列 仲裁队列 非持久化队列 支持 不支持 排他队列 支持 不支持 每条消息的持久化 每条消息 永远 队列重平衡 自动 手动 消息超时时间 支持 不支持 队列超时时间 支持 支持 队列长度限制 支持 支持（除xoverflow: rejectpublishdlx） 惰性队列 支持 限制队列长度后支持 消息优先级 支持 不支持 消费优先级 支持 支持 死信交换器 支持 支持 动态Policy 支持 支持 毒药消息（让消费者无限循环消费）处理 不支持 支持 全局消息预取（Qos） 支持 不支持

消息TTL Time To Live，也就是生存时间，是一条消息在队列中的最大存活时间，单位是毫秒。 RabbitMQ可以对消息和队列设置TTL。 RabbitMQ支持设置消息的过期时间，在消息发送的时候可以进行指定，每条消息的过期时间可以不同。 RabbitMQ支持设置队列的过期时间，从消息入队列开始计算，直到超过了队列的超时时间配置，那么消息会变成死信，自动清除。 如果两种方式一起使用，则过期时间以两者中较小的那个数值为准。 当然也可以不设置TTL，不设置表示消息不会过期；如果设置为0，则表示除非此时可以直接将消息投递到消费者，否则该消息将被立即丢弃。 持久化 RabbitMQ的持久化分为三个部分：交换器持久化、队列持久化和消息的持久化。 交换器持久化可以通过在声明队列时将durable参数设置为true。如果交换器不设置持久化，那么在RabbitMQ服务重启之后，相关的交换器元数据会丢失，不过消息不会丢失，只是不能将消息发送到这个交换器了。 队列的持久化能保证其本身的元数据不会因异常情况而丢失，但是不能保证内部所存储的消息不会丢失。要确保消息不会丢失，需要将其设置为持久化。队列的持久化可以通过在声明队列时将durable参数设置为true。 设置了队列和消息的持久化，当RabbitMQ服务重启之后，消息依然存在。如果只设置队列持久化或者消息持久化，重启之后消息都会消失。 对于可靠性不是那么高的消息可以不采用持久化处理以提高整体的吞吐量。在实际中，需要根据实际情况在可靠性和吞吐量之间做一个权衡。

本节介绍了分布式消息服务RabbitMQ产品常见计费类问题。 支持哪些付费方式？ 支持包年包月和按需计费。 产品规格可选择哪些？ 分布式消息服务RabbitMQ是基于高可用、分布式集群技术，完全兼容RabbitMQ开源社区，支持消息路由、事务消息、优先级队列、延迟队列、死信队列、镜像队列等功能的消息云服务，更多产品信息请参见产品规格。 如何选择磁盘空间？ 在集群模式中，RabbitMQ需要对消息持久化写入到磁盘中，因此，在创建RabbitMQ实例选择存储空间时，建议根据业务消息体积预估以及镜像队列副本数量选择合适的存储空间。镜像队列副本数最大为集群的节点数。 例如：业务消息体积预估100GB，则磁盘容量最少应为100GB节点数 + 预留磁盘大小100GB。

本文主要介绍分布式消息服务RabbitMQ的实例规格。 RabbitMQ实例规格 RabbitMQ实例兼容开源RabbitMQ 3.8.35，实例类型包括单机和集群，实例规格请参考下表。 说明 为了保证稳定性，服务端限制了单条消息的最大长度为50MB，请勿发送大于此长度的消息。 下表中TPS，是指以2KB大小的消息为例的每秒处理消息条数，测试场景为不开启持久化的非镜像队列，实时生产实时消费，队列无积压。此数据仅供参考，生产使用需要以实际压测性能为准。 服务端的性能主要跟以下因素相关：队列数、消息堆积、连接数、channel、消费者数、镜像队列、优先级队列、消息持久化和exchange类型等，在选择实例规格时，请根据业务模型压测结果选择。 一条连接最多可以开启2047个channel。 表1 RabbitMQ实例规格 型号 代理数 存储空间范围 TPS参考值 单个代理最大消费者数 单个代理建议队列数 单个代理最大连接数 rabbitmq.2u4g.single 1 100GB~30000GB 10000 20000 200 3000 rabbitmq.4u8g.single 1 100GB~30000GB 20000 30000 400 4500 rabbitmq.8u16g.single 1 100GB~30000GB 35000 50000 800 7500 rabbitmq.16u32g.single 1 100GB~30000GB 45000 80000 1600 12000 rabbitmq.24u48g.single 1 100GB~30000GB 50000 100000 2400 15000 rabbitmq.2u4g.cluster 3/5/7 3/5/7100GB~30000GB 30000~70000 20000 200 3000 rabbitmq.4u8g.cluster 3/5/7 3/5/7100GB~30000GB 45000~80000 30000 400 4500 rabbitmq.8u16g.cluster 3/5/7 3/5/7100GB~30000GB 85000~120000 50000 800 7500 rabbitmq.12u24g.cluster 3/5/7 3/5/7100GB~30000GB 100000~150000 60000 1200 10000 rabbitmq.16u32g.cluster 3/5/7 3/5/7100GB~30000GB 130000~180000 80000 1600 12000 rabbitmq.24u48g.cluster 3/5/7 3/5/7100GB~30000GB 150000~200000 100000 2400 15000

介绍分布式消息服务RabbitMQ惰性队列能力。 使用场景 RabbitMQ从3.6.0版本开始引入了惰性队列（Lazy Queue）的概念。惰性队列会尽可能的将消息存入磁盘中，而在消费者消费到相应的消息时才会被加载到内存中，它的一个重要的设计目标是能够支持更长的队列，即支持更多的消息存储。当消费者由于各种各样的原因（比如消费者下线、宕机亦或者是由于维护而关闭等）而致使长时间内不能消费消息造成堆积时，惰性队列就很有必要了 默认情况下，当生产者将消息发送到RabbitMQ的时候，队列中的消息会尽可能的存储在内存之中，这样可以更加快速的将消息发送给消费者。即使是持久化的消息，在被写入磁盘的同时也会在内存中驻留一份备份。当RabbitMQ需要释放内存的时候，会将内存中的消息换页至磁盘中，这个操作会耗费较长的时间，也会阻塞队列的操作，进而无法接收新的消息。虽然RabbitMQ的开发者们一直在升级相关的算法，但是效果始终不太理想，尤其是在消息量特别大的时候 惰性队列会将接收到的消息直接存入文件系统中，而不管是持久化的或者是非持久化的，这样可以减少了内存的消耗，但是会增加I/O的使用，如果消息是持久化的，那么这样的I/O操作不可避免，惰性队列和持久化消息可谓是“最佳拍档”。注意如果惰性队列中存储的是非持久化的消息，内存的使用率会一直很稳定，但是重启之后消息一样会丢失。

本文主要介绍分布式消息服务RabbitMQ的惰性队列。 使用场景 默认情况下，RabbitMQ生产者生产的消息存储在内存中，当需要释放内存时，会将内存中的消息换页至磁盘中。换页操作会消耗较长的时间，且换页过程中队列无法处理消息。 如果生产速度过快（例如执行批处理任务），或者消费者由于各种原因（例如消费者下线、宕机）长时间内无法消费消息，导致消息大量堆积，使得内存使用率过高，换页频繁，可能会影响其他队列的消息收发。这种场景下，建议您启用惰性队列。 惰性队列（Lazy Queue）会尽可能的将消息存入磁盘中，在消费者消费到相应的消息时才会被加载到内存中，这样可以减少内存的消耗，但是会增加I/O的使用，影响单个队列的吞吐量。惰性队列的一个重要的设计目标是能够支持更长的队列，即支持更多的消息存储/消息堆积。 在以下情况下，推荐使用惰性队列： 队列可能会产生消息堆积 队列对性能（吞吐量）的要求不是非常高，例如TPS 1万以下的场景 希望队列有稳定的生产消费性能，不受内存影响而波动 处于以下情况时，无需使用惰性队列： RabbitMQ需要高性能的场景 队列总是很短（即队列中没有消息堆积） 设置了最大长度策略 更多关于惰性队列的说明，请参考Lazy Queues。

本章节主要介绍分布式消息服务RabbitMQ的死信和TTL。 死信和TTL（Time To Live）是RabbitMQ中需要慎用的2个特性，它们可能会对性能产生负面影响。 死信 死信是RabbitMQ中的一种消息机制，在消费消息时，如果队列里的消息满足以下任意一种情况，那么该消息将成为“死信”。 “requeue”被设置为“false”，消费者使用“basic.reject”或“basic.nack”否定应答（NACK）消息。 消息在队列的存活时间超过设置的TTL时间。 队列的消息数量已经超过最大队列长度。 死信消息会被RabbitMQ进行特殊处理，如果配置了死信队列信息，该消息将会被存储到死信队列中，如果没有配置，该消息将会被丢弃。 更多关于死信的说明，请参考Dead Letter Exchanges。 使用队列参数配置死信交换机和路由 为队列配置死信交换机，并在申明队列时指定“xdeadletterexchange”和“xdeadletterroutingkey”参数。队列根据“xdeadletterexchange”将死信消息发送到死信交换机中，并根据“xdeadletterroutingkey”为死信消息设置死信路由Key。 以下示例演示在Java客户端配置死信交换机和路由： channel.exchangeDeclare("some.exchange.name", "direct"); Map args new HashMap (); args.put("xdeadletterexchange", "some.exchange.name"); args.put("xdeadletterroutingkey", "someroutingkey"); channel.queueDeclare("myqueue", false, false, false, args); TTL TTL即过期时间。RabbitMQ支持设置消息和队列的TTL，消息的TTL可以通过以下两种方法设置： 通过队列属性设置：队列中所有消息的具有相同的过期时间。 对消息本身单独设置：每条消息可以设置不同的TTL。 如果两种方法同时使用，以较小的TTL为准。 消息在队列中的生存时间超过了TTL后，消息会被丢弃，如果队列设置了死信交换机，丢弃的消息会被转发到死信交换机，由死信交换机将其路由到死信队列。 更多关于TTL的说明，请参考TTL。

异步通信 RabbitMQ是一个消息中间件，可以用于异步通信。在用户注册场景中，RabbitMQ可以用于发送和接收注册相关的消息。 下面是一个异步用户注册流程： 1. 用户提交注册表单。 2. 服务器接收到注册请求后，将用户提交的数据写入数据库，并生成一个唯一的用户ID。 3. 服务器将用户ID封装成一个消息，发送到RabbitMQ的注册队列中。 4. 注册队列中的消息被一个或多个消费者监听。 5. 消费者接收到注册消息后，执行注册相关的逻辑，比如发送确认邮件、生成用户账号等操作。 6. 在完成注册逻辑后，消费者可以将结果封装成一个消息，发送到另一个队列中，比如发送注册成功通知给用户。 7. 另一个队列中的消息可以由一个或多个消费者监听，负责处理注册成功通知的逻辑。 使用RabbitMQ实现异步用户注册可以带来以下好处： 解耦：通过将注册请求和注册逻辑解耦，使得系统组件之间的依赖减少。 异步处理：用户不需要等待注册逻辑完成，而是可以立即返回一个成功的响应。真正的注册逻辑可以在后台完成，提高系统的并发能力。 可伸缩性：通过添加更多的消费者来处理注册消息，可以轻松地提高系统的吞吐量。 可靠性：RabbitMQ具备持久化消息的能力，即使在发生故障时也不会丢失消息。 需要注意的是，使用RabbitMQ进行异步通信需要对消息的可靠性进行处理，比如使用事务或者消息确认机制，以确保消息能够被成功处理。 高可用 RabbitMQ提供了多种方式来实现高可用性，确保消息队列的稳定和可靠性。以下是一些常用的方法： 1. 集群模式：RabbitMQ支持将多个节点组成集群，通过在多个节点之间复制消息队列和交换器，实现数据的冗余和高可用性。当一个节点发生故障时，其他节点可以接管其工作，确保消息的连续传递。 2. 镜像队列：RabbitMQ的镜像队列功能可以将队列的数据在多个节点之间进行复制。这样，当一个节点发生故障时，其他节点上的镜像队列可以继续提供服务，确保消息的可靠传递。 3. 自动化故障转移：RabbitMQ支持自动故障转移，当一个节点发生故障时，可以自动将其上的队列和交换器迁移到其他正常的节点上，确保消息的连续处理。 4. 心跳机制：RabbitMQ通过心跳机制来监测节点的健康状态。当一个节点长时间没有响应时，其他节点可以将其标记为不可用，并进行故障转移。 5. 负载均衡：通过在多个节点之间分配消息的处理负载，可以提高系统的吞吐量和可用性。RabbitMQ支持多种负载均衡算法，如轮询、随机等。 6. 数据备份和恢复：为了防止数据丢失，可以定期备份RabbitMQ的数据，并在节点故障时进行数据恢复。 通过以上的方法，可以实现RabbitMQ的高可用性，确保消息队列的稳定运行和数据的可靠传递。但是需要注意的是，高可用性的实现需要根据具体的需求和场景进行配置和调优。

消息创建时间在哪设置？ 消息创建时间是在生产消息时由生产客户端设置。 RabbitMQ是否支持跨Region部署？ 不支持跨Region部署。 如何清空队列数据？ （1）进入“分布式消息服务RabbitMQ”控制中心； （2）在“实例列表”页面点击对应的RabbitMQ实例； （3）在“队列管理”页面点击要清空的队列； （4）在“清除消息”页面点击清空队列。 RabbitMQ支持升级CPU和内存吗？ RabbitMQ支持扩容规格。 如何设置Message ID？ 如需追踪和识别消息，可以在分布式消息服务RabbitMQ的Producer客户端设置Message ID属性，为每条消息设置唯一标识符。 在分布式消息服务RabbitMQ的Producer客户端设置Basic.Properties的messageid属性。示例代码如下： AMQP.BasicProperties props newAMQP.BasicProperties.Builder().messageId("messageid").build(); channel.basicPublish("ExchangeName","RoutingKey",true, props,("消息发送Body").getBytes()); Message ID（消息标识符）是消息的可选属性，类型为String。Message ID在业务上通常被设置为唯一，适用于追踪和识别销售单、工单等需要保证消息唯一的场景。分布式消息服务RabbitMQ服务端不会对消息进行幂等处理。如需实现消息幂等，即如果消息重试多次，消费者端对该重复消息消费多次与消费一次的结果是相同的，并且多次消费没有对系统产生副作用，在为每条消息设置唯一Message ID的基础上，还需要在分布式消息服务RabbitMQ的Consumer客户端对消息进行幂等处理。

本文主要介绍分布式消息服务RabbitMQ的惰性队列最佳实践。 使用场景 默认情况下，RabbitMQ生产者生产的消息存储在内存中，当需要释放内存时，会将内存中的消息换页至磁盘中。换页操作会消耗较长的时间，且换页过程中队列无法处理消息。 如果生产速度过快（例如执行批处理任务），或者消费者由于各种原因（例如消费者下线、宕机）长时间内无法消费消息，导致消息大量堆积，使得内存使用率过高，换页频繁，可能会影响其他队列的消息收发。这种场景下，建议您启用惰性队列。 惰性队列（Lazy Queue）会尽可能的将消息存入磁盘中，在消费者消费到相应的消息时才会被加载到内存中，这样可以减少内存的消耗，但是会增加I/O的使用，影响单个队列的吞吐量。惰性对列的一个重要的设计目标是能够支持更长的队列，即支持更多的消息存储/消息堆积。 在以下情况下，推荐使用惰性队列： 队列可能会产生消息堆积 队列对性能（吞吐量）的要求不是非常高，例如TPS 1万以下的场景 希望队列有稳定的生产消费性能，不受内存影响而波动 处于以下情况时，无需使用惰性队列： RabbitMQ需要高性能的场景 队列总是很短（即队列中没有消息堆积） 设置了最大长度策略 设置惰性队列 队列具备两种模式：default和lazy，默认模式为default。lazy模式即为惰性队列的模式，可以通过调用channel.queueDeclare方法的时候在参数中设置，也可以通过Policy的方式设置。如果一个队列同时使用这两种方式设置的话，Policy的方式具备更高的优先级。 以下示例演示在Java客户端通过调用channel.queueDeclare设置惰性队列。 Map args new HashMap (); args.put("xqueuemode", "lazy"); channel.queueDeclare("myqueue", false, false, false, args); 以下示例演示在RabbitMQ的Web界面通过Policy的方式设置惰性队列。 更多关于惰性队列的说明，请参考Lazy Queues 。

本文主要介绍如何实现RabbitMQ的高性能最佳实践。 本章节基于吞吐量和可靠性两个指标，指导您通过设置队列长度、集群负载均衡、优先队列数量等参数，实现RabbitMQ的高性能。 使用较小的队列长度 队列中存在大量消息时，会给内存使用带来沉重的负担，为了释放内存，RabbitMQ会将消息刷新到磁盘。这个过程通常需要时间，由于需要重建索引，重启包含大量消息的集群非常耗时。当刷盘的消息过多时，会阻塞队列处理消息，从而降低队列速度，对RabbitMQ节点的性能产生负面影响。 要获得最佳性能，应尽可能缩短队列。建议始终保持队列消息堆积的数量在0左右。 对于经常受到消息峰值影响的应用程序，和对吞吐量要求较高的应用程序，建议在队列上设置 最大长度 。这样可以通过丢弃队列头部的消息来保持队列长度，队列长度永远不会大于最大长度设置。 最大长度可以通过Policy设置，也可以通过在队列声明时使用对应参数设置。 在Policy中设置 在队列声明时使用对应参数设置 //创建队列 HashMap map new HashMap<>(); //设置队列最大长度 map.put("xmaxlength",10 ); //设置队列溢出方式保留前10 map.put("xoverflow","rejectpublish" ); channel.queueDeclare(queueName,false,false,false,map); 当队列长度超过设置的最大长度时，RabbitMQ的默认做法是将队列头部的信息（队列中最老的消息）丢弃或变成死信。可以通过设置不同的overflow 值来改变这种方式，如果overflow 值设置为 drophead ，表示从队列前面丢弃或deadletter消息，保存后n条消息。如果overflow 值设置为 rejectpublish ，表示最近发布的消息将被丢弃，即保存前n条消息。 说明 如果同时使用以上两种方式设置队列的最大长度，两者中较小的值将被使用。 超过队列最大长度的消息会被丢弃，请谨慎使用。

本文主要介绍分布式消息服务RabbitMQ的实例规格。 RabbitMQ实例规格 RabbitMQ实例兼容开源RabbitMQ 3.8.35，实例类型包括单机和集群，实例规格请参考下表。 说明 为了保证稳定性，服务端限制了单条消息的最大长度为50MB，请勿发送大于此长度的消息。 下表中TPS，是指以2KB大小的消息为例的每秒处理消息条数，测试场景为不开启持久化的非镜像队列，实时生产实时消费，队列无积压。此数据仅供参考，生产使用需要以实际压测性能为准。 服务端的性能主要跟以下因素相关：队列数、消息堆积、连接数、channel、消费者数、镜像队列、优先级队列、消息持久化和exchange类型等，在选择实例规格时，请根据业务模型压测结果选择。 一条连接最多可以开启2047个channel。 表1 RabbitMQ实例规格 型号 代理数 存储空间范围 TPS参考值 单个代理最大消费者数 单个代理建议队列数 单个代理最大连接数 rabbitmq.2u4g.single 1 100GB~30000GB 10000 20000 200 3000 rabbitmq.4u8g.single 1 100GB~30000GB 20000 30000 400 4500 rabbitmq.8u16g.single 1 100GB~30000GB 35000 50000 800 7500 rabbitmq.16u32g.single 1 100GB~30000GB 45000 80000 1600 12000 rabbitmq.24u48g.single 1 100GB~30000GB 50000 100000 2400 15000 rabbitmq.2u4g.cluster 3/5/7 3/5/7100GB~30000GB 30000~70000 20000 200 3000 rabbitmq.4u8g.cluster 3/5/7 3/5/7100GB~30000GB 45000~80000 30000 400 4500 rabbitmq.8u16g.cluster 3/5/7 3/5/7100GB~30000GB 85000~120000 50000 800 7500 rabbitmq.12u24g.cluster 3/5/7 3/5/7100GB~30000GB 100000~150000 60000 1200 10000 rabbitmq.16u32g.cluster 3/5/7 3/5/7100GB~30000GB 130000~180000 80000 1600 12000 rabbitmq.24u48g.cluster 3/5/7 3/5/7100GB~30000GB 150000~200000 100000 2400 15000

本节介绍了如何实现RabbitMQ的高性能。 使用较小的队列长度 队列中存在大量消息时，会给内存使用带来沉重的负担，为了释放内存，RabbitMQ会将消息刷新到磁盘。这个过程通常需要时间，由于需要重建索引，重启包含大量消息的集群非常耗时。当刷盘的消息过多时，会阻塞队列处理消息，从而降低队列速度，对RabbitMQ节点的性能产生负面影响。 要获得最佳性能，应尽可能缩短队列。建议始终保持队列消息堆积的数量在0左右。 对于经常受到消息峰值影响的应用程序，和对吞吐量要求较高的应用程序，建议在队列上设置最大长度。这样可以通过丢弃队列头部的消息来保持队列长度，队列长度永远不会大于最大长度设置。 在队列声明时使用对应参数设置。 java //创建队列 HashMap map new HashMap<>(); //设置队列最大长度 map.put("xmaxlength",10 ); //设置队列溢出方式保留前10 map.put("xoverflow","rejectpublish" ); channel.queueDeclare(queueName,false,false,false,map); 当队列长度超过设置的最大长度时，RabbitMQ的默认做法是将队列头部的信息（队列中最老的消息）丢弃或变成死信。可以通过设置不同的overflow值来改变这种方式，如果overflow值设置为drophead，表示从队列前面丢弃或deadletter消息，保存后n条消息。如果overflow值设置为rejectpublish，表示最近发布的消息将被丢弃，即保存前n条消息。 自动删除不再使用的队列 客户端可能连接失败导致队列被残留，大量的残留队列会影响实例的性能。RabbitMQ提供三种自动删除队列的方法： 在队列中设置TTL策略：例如TTL策略设置为28天，当持续28天队列未被使用时，此队列将被删除。 使用autodelete队列：当最后一个消费者退出或通道/连接关闭（或与服务器的TCP连接丢失）时，autodelete队列会被删除。 使用exclusive queue：exclusive queue只能在创建它的连接中使用，当此连接关闭或消失时，exclusive queue会被删除。 设置方法如下： java boolean exclusive true; boolean autoDelete true; channel.queueDeclare(QUEUENAME, durable, exclusive, autoDelete, arguments);

本节介绍了在RabbitMQ实例中如何创建、修改和删除操作策略。 背景信息 RabbitMQ操作策略管理是一种用于管理RabbitMQ服务器的功能，它允许管理员定义和控制各种操作策略以满足特定的需求和约束。 操作策略可以应用于多个方面，包括队列、交换机、绑定和连接等。通过操作策略管理，管理员可以定义以下内容： ● 长度限制：管理员可以设置队列的最大长度，以防止队列无限增长导致资源耗尽。当队列达到指定的长度限制时，可以选择丢弃新的消息或者拒绝新的连接。 ● 时间限制：管理员可以设置队列中消息的最大存活时间，以防止消息在队列中长时间滞留。一旦消息超过指定的时间限制，可以选择将其丢弃或者转发到其他队列。 ● 内存限制：管理员可以设置队列或交换机的最大内存使用量，以防止RabbitMQ服务器的内存资源被过度消耗。当达到指定的内存限制时，可以选择丢弃消息或者拒绝新的连接。 ● 消息优先级：管理员可以为消息设置优先级，以确保重要的消息能够优先处理。可以通过操作策略管理来定义消息优先级的规则和行为。 ● 连接限制：管理员可以设置连接的最大数量，以限制同时连接到RabbitMQ服务器的客户端数量。这可以用于控制系统的负载和资源消耗。 通过操作策略管理，管理员可以根据实际需求和约束对RabbitMQ服务器进行细粒度的控制和管理。这有助于提高系统的可靠性、性能和可伸缩性，并确保消息队列系统能够适应各种场景和负载。

功能项 RocketMQ Kafka RabbitMQ 优先级队列 不支持 不支持 支持。建议优先级大小设置在010之间。 延迟队列 支持 不支持 不支持 死信队列 支持 不支持 支持 消息重试 支持 不支持 不支持 消费模式 支持客户端主动拉取和服务端推送两种方式 客户端主动拉取 支持客户端主动拉取以及服务端推送两种模式 广播消费 支持 支持 支持 消息回溯 支持 支持。Kafka支持按照offset和timestamp两种维度进行消息回溯。 不支持。RabbitMQ中消息一旦被确认消费就会被标记删除。 消息堆积 支持 支持。考虑吞吐因素，Kafka的堆积效率比RabbitMQ总体上要高。 支持 持久化 支持 支持 支持 消息追踪 支持 不支持 支持。RabbitMQ中可以采用Firehose或者rabbitmqtracing插件实现，但开启rabbitmqtracing插件会影响性能，建议只在定位问题过程中开启。 消息过滤 支持 支持 不支持，但可以自行封装。 多租户 支持 不支持 支持 多协议支持 兼容RocketMQ协议 只支持Kafka自定义协议。 RabbitMQ基于AMQP协议实现，同时支持MQTT、STOMP等协议。 跨语言支持 支持多语言的客户端 采用Scala和Java编写，支持多种语言的客户端。 采用Erlang编写，支持多种语言的客户端。 流量控制 待规划 支持client和user级别，通过主动设置可将流控作用于生产者或消费者。 RabbitMQ的流控基于CreditBased算法，是内部被动触发的保护机制，作用于生产者层面。 消息顺序性 单队列（queue）内有序 支持单分区（partition）级别的顺序性。 不支持。需要单线程发送、单线程消费并且不采用延迟队列、优先级队列等一些高级功能整体配合，才能实现消息有序。 安全机制 支持SSL认证 支持SSL、SASL身份认证和读写权限控制。 与Kafka相似 事务性消息 支持 支持 支持

本节介绍了编译工程生产消费的主要内容点,包括引入依赖、绑定BindingKey、生产消息和消费消息。 前提条件 创建分布式消息服务RabbitMQ实例。 操作步骤 RabbitMQ是一个开源的消息队列中间件，支持生产者和消费者之间的异步通信。在上述资源准备完成后，接下来需要编译工程生产消费，主要分以下几个步骤： 1、编写生产者代码：编写一个生产者程序。该程序将连接到RabbitMQ服务器，并将消息发送到队列中。 2、编写消费者代码：编写一个消费者程序。该程序将连接到RabbitMQ服务器，并从队列中接收消息。 3、运行生产者和消费者：运行生产者程序，它将发送消息到队列中。然后运行消费者程序，它将从队列中接收并处理消息。 4、验证结果：检查生产者和消费者程序的输出，确保消息被正确发送和接收。 引入依赖 在使用RabbitMQ时，你需要在你的项目中引入相应的依赖。具体的依赖项可能会因你的项目和需求而有所不同。在使用RabbitMQ之前，请确保查阅官方文档以获取最新的依赖项和使用说明。 以Java编程语言为例，可以使用RabbitMQ的Java客户端库。你可以在Maven或Gradle构建工具中添加以下依赖项： com.rabbitmq amqpclient 5.7.0 也可以通过下载JAR包来引入依赖。 绑定BindingKey 在RabbitMQ中，绑定键（Binding Key）是用于绑定交换机（Exchange）和队列（Queue）的关键字。当一个消息被发送到交换机时，交换机会根据绑定键将消息路由到相应的队列中。 绑定键是在创建绑定（Binding）时指定的，它定义了消息应该如何被路由到队列。绑定键通常与消息的属性或内容进行匹配，以确定消息应该发送到哪个队列。 绑定键可以具有不同的形式，取决于使用的交换机类型。以下是一些常见的绑定键形式： 直接匹配（Direct Match）：绑定键与消息的路由键（Routing Key）完全匹配时，消息会被路由到相应的队列。 通配符匹配（Wildcard Match）：绑定键可以使用通配符进行模式匹配。常见的通配符有和

本节介绍了分布式消息服务RabbitMQ产品常见管理类问题。 重启RabbitMQ实例时，若其中一台RabbitMQ重启失败，会如何处理？ 重启RabbitMQ实例时，不会重启实例所在虚拟机，仅重启RabbitMQ进程。 重启集群实例时，若其中一台RabbitMQ进程重启失败，则重启后实例状态依然为“运行中”，并提示“部分节点故障”。在每台虚拟机上都有RabbitMQ的守护进程，定时检查RabbitMQ进程是否存在，当进程不存在时会自动拉起RabbitMQ进程。 如果RabbitMQ实例异常持续超过1分钟，会上报告警。 RabbitMQ集群实例如何均衡分发请求到每个虚拟机？ 集群内部使用LVS做负载均衡，由LVS将请求均衡分发到每个虚拟机节点。 RabbitMQ实例是否支持持久化，如何定时备份数据？ RabbitMQ支持消息数据持久化，可从客户端连接RabbitMQ并设置消息持久化，也可在RabbitMQ集群管理工具界面创建队列时设置消息持久化。 不支持客户自定义定时备份数据，或从界面触发备份数据。 RabbitMQ实例开启SSL开关后，证书如何获取？ RabbitMQ实例开启SSL后只做单向认证，不需要证书。 RabbitMQ实例的SSL开关是否支持修改？ 不支持动态修改，即如果实例创建时没有选择开启，创建完成之后，不支持修改，建议在实例创建时将开关打开。 RabbitMQ实例支持延迟消息队列么？ RabbitMQ可以通过设置消息的有效期、和死信队列来实现延迟消息。 同时，也提供安装插件实现延迟消息。

本章节介绍了分布式消息服务RocketMQ与Kafka和RabbitMQ的差异。 功能项 RocketMQ Kafka RabbitMQ 优先级队列 不支持 不支持 支持。建议优先级大小设置在010之间。 延迟队列 支持 不支持 不支持 死信队列 支持 不支持 支持 消息重试 支持 不支持 不支持 消费模式 支持客户端主动拉取和服务端推送两种方式 客户端主动拉取 支持客户端主动拉取以及服务端推送两种模式 广播消费 支持 支持 支持 消息回溯 支持 支持。Kafka支持按照offset和timestamp两种维度进行消息回溯。 不支持。RabbitMQ中消息一旦被确认消费就会被标记删除。 消息堆积 支持 支持。考虑吞吐因素，Kafka的堆积效率比RabbitMQ总体上要高。 支持 持久化 支持 支持 支持 消息追踪 支持 不支持 支持。RabbitMQ中可以采用Firehose或者rabbitmqtracing插件实现，但开启rabbitmqtracing插件会影响性能，建议只在定位问题过程中开启。 消息过滤 支持 支持 不支持，但可以自行封装。 多租户 支持 不支持 支持 多协议支持 兼容RocketMQ协议 只支持Kafka自定义协议。 RabbitMQ基于AMQP协议实现，同时支持MQTT、STOMP等协议。 跨语言支持 支持多语言的客户端 采用Scala和Java编写，支持多种语言的客户端。 采用Erlang编写，支持多种语言的客户端。 流量控制 待规划 支持client和user级别，通过主动设置可将流控作用于生产者或消费者。 RabbitMQ的流控基于CreditBased算法，是内部被动触发的保护机制，作用于生产者层面。 消息顺序性 单队列（queue）内有序 支持单分区（partition）级别的顺序性。 不支持。需要单线程发送、单线程消费并且不采用延迟队列、优先级队列等一些高级功能整体配合，才能实现消息有序。 安全机制 支持SSL认证 支持SSL、SASL身份认证和读写权限控制。 与Kafka相似 事务性消息 支持 支持 支持

本文主要介绍分布式消息服务RabbitMQ的入门实践。 当您购买了RabbitMQ实例后，可以根据自身的业务需求使用分布式消息服务RabbitMQ提供的一系列常用实践。 表1 常用最佳实践 实践 描述 RabbitMQ业务迁移 介绍将线下单机或集群实例迁移到天翼云RabbitMQ实例的方案。 RabbitMQ队列迁移 扩容节点、删除队列可能会导致队列在各个节点分布不均衡，本文介绍如何设置队列负载均衡。

介绍分布式消息服务RabbitMQ消息持久化功能。 使用场景 在生产过程中，难免会发生服务器宕机的事情，RabbitMQ也不例外，可能由于某种特殊情况下的异常而导致RabbitMQ宕机从而重启，那么这个时候对于消息队列里的数据，包括交换机、队列以及队列中存在消息恢复就显得尤为重要了。RabbitMQ本身带有持久化机制，包括交换机、队列以及消息的持久化。持久化的主要机制就是将信息写入磁盘，当RabbtiMQ服务宕机重启后，从磁盘中读取存入的持久化信息，恢复数据。 设置交换器持久化 （1）登录管理控制台。 （2）进入RabbitMQ管理控制台。 （3）在实例列表页在操作列，目标实例行点击“管理”。 （4）点击“交换器管理”后，点击“新建”按钮。 （5）点击“新建”后出现以下窗口，是否持久化选择是。 设置队列持久化 （1）登录管理控制台。 （2）进入RabbitMQ管理控制台。 （3）在实例列表页在操作列，目标实例行点击“管理”。 （4）点击“队列管理”后，点击“新建”按钮。 （5）点击“新建”后出现以下窗口，是否持久化选择是。

本文介绍如何应用事件总线EventBridge的事件流功能实现分布式消息服务RabbitMQ的消息路由。 前提条件 开通事件总线EventBridge并授权。 开通分布式消息服务RabbitMQ并开通实例。 背景信息 事件流作为更轻量、实时端到端的流式事件通道，提供轻量级的流式数据的过滤和转换的能力，在不同的数据仓库之间、数据处理程序之间、数据分析和处理系统之间进行数据同步。源端分布式消息服务RabbitMQ生产的消息可以通过事件流这个通道被路由到目标端的分布式消息服务RabbitMQ。 步骤一：创建事件流 1. 登录事件总线EventBridge控制台。 2. 在左侧导航栏，单击事件流。 3. 在事件流页面，单击创建事件流。 4. 在创建事件流面板，设置任务名称和描述，配置以下参数，然后单击保存。 a.在Source（源） 配置向导，选择数据提供方为分布式消息服务RabbitMQ，设置以下参数，然后单击下一步。 参数 说明 示例 RabbitMQ实例 选择分布式消息服务RabbitMQ实例。 instancexxx RabbitMQ vhost 选择分布式消息服务RabbitMQ vhost。 / RabbitMQ queue 选择分布式消息服务RabbitMQ queue。 queuexxx b.在Filtering（过滤）配置向导，设置事件过滤规则，单击下一步。 c.在Sink（目标） 配置向导，选择服务类型为分布式消息服务RabbitMQ，配置以下参数，单击保存，如图1所示。 图1 创建事件流时源的类型选择分布式消息服务RabbitMQ 参数 说明 示例 实例 选择分布式消息RabbitMQ实例。 instancexxx Vhost 选择RabbitMQ实例的Vhost。 POST 目标类型 选择发送到RabbitMQ的目标类型。 1. 交换器：通过选择交换器和路由键，事件带上路由键会发送到所选择交换器。 2. 队列：事件会发送到目标队列。 队列 queuexxx 消息体 选择作为消息体的事件内容，更多参考“事件内容转换”。 完整事件 MessageId 选择MessageId的内容，更多参考“事件内容转换”。 空 自定义属性 选择自定义属性（Properties）的内容，更多参考“事件内容转换”。 空 创建事件流后，会有30秒~60秒的延迟时间，您可以在事件流页面的状态栏查看启动进度。