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

应用架构 支持的功能模块 应用双活 管控通道 注册配置中心RCC 应用双活 接入层 云原生网关CGW 应用双活 服务层 SpringCloud 应用双活 服务层 Dubbo 应用双活 数据层 关系型数据库MySQL版 应用双活 数据层 关系型数据库PostgreSQL版 应用双活 消息层 分布式消息服务RocketMQ 数据双活 管控通道 注册配置中心RCC 数据双活 接入层 云原生网关CGW 数据双活 服务层 SpringCloud 数据双活 服务层 Dubbo 数据双活 数据层 关系型数据库MySQL版 数据双活 数据层 关系型数据库PostgreSQL版 数据双活 消息层 分布式消息服务RocketMQ

消息堆积对业务有什么影响？ 为了保证服务的稳定可靠，分布式消息服务RabbitMQ版采用了默认的40%高水位配置。当内存占用率达到40%高水位后，会触发流控，生产者流程会被阻塞。消息堆积可能造成内存高水位，为了避免高水位的产生，请及时消费积压在队列中的消息。 消费的最长保留时间是多久？ 一般情况下消息如果未被消费会一直保留，只有被消费后，才会被删除。但是如果设置了过期时间（TTL），则以TTL时间为准。

本章节介绍了如何修改分布式消息服务RocketMQ实例的消费组参数。 操作场景 消费组创建成功后，您可以根据业务需要修改以下参数：最大重试次数、广播消费。 操作步骤 1. 登录分布式消息服务RocketMQ控制台。 2. 单击RocketMQ实例的名称，进入实例详情页面。 3. 在左侧导航栏，单击“消费组管理”，进入“消费组管理”页面。 4. 选择以下任意一种方法修改消费组参数。 在待修改的消费组所在行，单击“编辑”，弹出“编辑消费组”页面。 单击待修改的消费组名称，进入消费组详情页面。在页面右上角，单击“编辑”，弹出“编辑消费组”页面。 图1 编辑消费组 图2 编辑消费组 5. 修改如表1所示配置信息。 表1 消费组参数说明 参数 说明 最大重试次数 设置消费失败的最大重试次数。 广播消费 是否设置为广播消费。 若开启广播消费，每条消息都会被消费组内的所有消费者消费一次。否则，每条消息只会被消费组内的某一消费者消费。 6. 修改完成后，单击“确定”。

本文主要介绍分布式消息服务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 。

场景描述 在RocketMQ中，创建消费组的场景可以有以下几种情况： ● 消息负载均衡：当一个Topic的消息量较大时，可以创建多个消费者，并将它们加入同一个消费组。RocketMQ会根据消费者的负载均衡策略，将消息均匀地分发给消费组中的消费者，从而实现消息的负载均衡。 ● 高可用性：为了提高消费者的可用性和容错能力，可以创建多个消费者，并将它们加入同一个消费组。当其中一个消费者发生故障或停止运行时，RocketMQ会将该消费者的消息重新分发给消费组中的其他消费者，从而实现高可用性。 ● 消费者水平扩展：当需要提高消费能力时，可以创建多个消费者，并将它们加入同一个消费组。RocketMQ会根据消费者的数量和负载均衡策略，将消息均匀地分发给消费组中的消费者，从而提高消费能力。 ● 消费者组管理：通过创建消费组，可以对一组具有相同消费逻辑的消费者进行管理。例如，可以对相同业务逻辑的消费者进行分组，并为每个消费组设置不同的消费策略、消费进度等参数。 需要注意的是，创建消费组时需要为其指定一个唯一的名称，以便在RocketMQ中进行标识和管理。同时，消费组可以消费一个或多个Topic，以满足不同业务场景的需求。 总之，通过创建消费组，可以实现消息的负载均衡、高可用性和消费者水平扩展，同时方便对消费者组进行管理和配置。 新增消费组 1、进入消费组管理菜单，点击【创建消费组】按钮 2、 在弹出的新建消费组窗口填写相应字段。 1）默认展示当前集群名称，不可修改。 2）填写消费组名称，名字限制2到64个字符，超过限制会导致创建消费组失败，用户创建消费组只能包含大小写字母数字以及和符号。 3）按照实际需求填写消费组备注。 4）选择消费组所在的Broker，按照实例创建时候选择的主备节点对数列出每个broker，可复选。 5）选择是否开启消费，默认开启消费。 3、 完成消费组信息填写后，保存确认即可新增消费组。 4、 若希望批量创建消费组，可点击【导入消费组】按钮 批量创建 注意：注意输入的订阅组名不要带空格等特殊字符 通过csv格式模板上传，批量创建订阅组。格式：点击【订阅组模板】按钮下载。 消费组模板 指批量上传消费组的模板，必须使用模板，才能够上传成功，模板格式如下：

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

本章节介绍了如何删除分布式消息服务RocketMQ实例的消费组。 操作场景 消费组无需继续使用，需要清理时，参考本章节删除消费组。 操作步骤 1. 登录分布式消息服务RocketMQ控制台。 2. 单击RocketMQ实例的名称，进入实例详情页面。 3. 在左侧导航栏，单击“消费组管理”，进入“消费组管理”页面。 图1 删除消费组 4. 选择以下任意一种方法删除消费组。 在待删除的消费组所在行，单击“删除”。 单击待删除的消费组名称，进入消费组详情页面。在页面右上角，单击“删除”。 如需批量删除消费组，勾选待删除的消费组，单击“删除消费组”。 5. 单击“是”，确认删除消费组。

延迟队列 一般的队列，消息一旦进入队列就会被消费者立即消费。延迟队列就是进入该队列的消息会被消费者延迟消费，延迟队列中存储的对象是的延迟消息，“延迟消息”是指当消息被发送以后，等待特定的时间后，消费者才能拿到这个消息进行消费。RabbitMQ提供TTL配合死信队列和延时队列插件两种方式来满足延时消息业务场景。 死信队列 当消息在一个队列中变成死信之后，他能被重新发送到另一个交换器中，这个交换器成为死信交换器，与该交换器绑定的队列称为死信队列。消息变成死信有下面几种情况： 消息被拒绝 消息过期 队列达到最大长度 DLX也是一个正常的交换器，和一般的交换器没有区别，他能在任何的队列上面被指定，实际上就是设置某个队列的属性。当这个队列中有死信的时候，RabbitMQ会自动将这个消息重新发送到设置的交换器上，进而被路由到另一个队列。当发生异常的时候，消息不能够被消费者正常消费，被加入到了死信队列中。后续的程序可以根据死信队列中的内容分析当时发生的异常，进而改善和优化系统。 优先级队列 优先级队列是指优先级高的消息往往放在队列的head头部，相比低优先级的消息，要优先投递给消费者进行处理。 在RabbitMQ中，我们可以设置消息的优先级，在发送消息时指定消息的优先级，可以分为10个级别，级别越高优先级越大。当多个消息拥有相同的优先级时，它们按照FIFO的顺序排序。

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

本文介绍分布式消息服务RocketMQ入门指引的创建应用用户和密码内容。 背景信息 新建消息实例后，必须新建应用用户，然后应用才能在此消息实例上发送、消费消息。 应用用户：指MQ客户端，连接服务器生产消费时，需要进行权限校验，所以MQ客户端的用户，称为应用用户；除了用户密码的校验，还可以为用户指定topic，代表该用户只能生产消费指定的topic，其他topic不能生产消费。 操作步骤 1、 天翼云官网点击控制中心，选择产品分布式消息服务RocketMQ。 2、 登录分布式消息服务RocketMQ控制台，点击右上角地域选择对应资源池。 3、 进入实例列表，点击【管理】按钮进入管理菜单。 4、进入应用用户管理（旧模式）或者角色控制（新模式）菜单。 （1）旧模式维护用户及权限 以下适用于上海6、北京4、内蒙5、西安3、重庆2、拉萨3、南京3、雄安2、晋中、郴州2、成都4、杭州2、上海7、西安4、福州3、泉州1、芜湖2、北京5、中卫2、贵州3、九江、内蒙6、武汉4、佛山3、福州4、昆明2、保定、乌鲁木齐27、辽阳1节点。 1）点击【新建用户】按钮 2）进入用户列表界面，新增用户 3）弹出框填写用户字段 默认展示租户名，不可修改。 选择集群名称，填写应用用户名，请输入大于6位字符，只能输入大小写字母，下划线，数字。 填写用户密码，请输入大于8位字符，需要包含数字大小写字母以及特殊符号(!@

参数 描述 虚拟主机 选择创建队列所属的虚拟主机 名称 队列的名称。以amq.开头的为保留字段，因此不能使用。例如：amq.test。 存储节点 队列数据存储节点 是否持久化 队列元数据是否持久化到磁盘 是否自动删除 最后一个Consumer取消订阅后，Queue是否自动删除。 其他参数 Message TTL消息过期时间：number型(单位:ms) Auto expire队列过期时间，过期后队列自动删除：number型(单位:ms) Max length队列能保存的最大消息数：number型(单位:个) Max length bytes队列能保存的最大消息量：number型(单位:字节) Overflow behaviour 超过队列的最大设定值后消息接收策略：drophead,rejectpublish drophead：删除头部消息,一般就是最早发送的消息，保证队列可用 rejectpublish：拒绝接受新的消息，保证消息不丢失 Dead letter exchange死信交换器名称 Dead letter routing key死信路由键 Maximum priority队列最大优先级：要开启消息的优先级，必须设置消息所在队列的优先级 Lazy mode队列惰性模式：default、lazy default：默认值，普通队列 lazy：惰性队列，尽可能将消息存到磁盘中，会引起I/O操作比较多，内存消耗极少（有大量堆积的持久化消息建议使用） Master Locator 队列保存位置：clientlocal、minmasters、random clientlocal：队列创建时所用连接的节点 minmasters： 集群中节点主数量最少的节点 random：由rabbitmq服务器随机指定一个节点

本文主要介绍如何实现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的功能特性主要体现在以下几个方面： 访问接口 支持通过API调用，提供交换器、队列增删查改等管控工作。管理控制台上进行的操作用于对交换器、队列、用户、策略等增删查改等管控工作。 队列能力 （1）优先级队列：相比低优先级的消息，要优先投递给消费者进行处理。 （2）延迟队列：延时消息，实现秒级精准定时；简单易用，在代码上只需一个参数设置即可完成，解决开源 RabbitMQ 无延时队列的痛点。 （3）死信队列：支持被拒绝消息、TTL 过期消息、队列达到最大长度（消息队列 AMQP 队列长度无上限）等 3 种类型消息自动进入死信队列的能力，确保消息不丢失。 消息能力 （1）广播消息：在同一个消费组内对所有消费者投递相同消息。 （2）事务消息：支持事务消息，可用于分布式应用。 （3）定时消息：支持消息延迟发送。解决开源 RabbitMQ 无延时队列的痛点。 安全防护 可追溯租户管理操作的记录。 起源于金融系统，支持权限控制和SSL协议。 运维监控 提供集群、交换器、队列的管理；集群、信道、连接、交换器、队列多维度指标监控。 更多信息请参见功能特性。 应用场景 分布式消息服务RabbitMQ适用于电子商务、金融服务、电信、物流和供应链管理、社交媒体、游戏开发、科学和研究领域等行业，通常用于业务的应用解耦、错峰流控与流量削峰、异步通信等场景。更多信息请参见应用场景。

本节介绍了如何实现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);

本章节介绍了分布式消息服务RocketMQ的标准资费价格。 RocketMQ支持ARM架构的鲲鹏实例，其规格、价格与X86架构相同。 包年优惠政策：一年8.5折、两年7折、三年5折。 实例规格名称 代理个数 按需（元/小时） 包周期（元/月） :::: rocketmq.4u8g.cluster.small 1 8.4 3,780 rocketmq.4u8g.cluster.small 2 16.8 7,560 rocketmq.4u8g.cluster 1 14 6,300 rocketmq.4u8g.cluster 2 22.4 10,080 rocketmq.4u8g.cluster 3 30.8 13,860 rocketmq.4u8g.cluster 4 39.2 17,640 rocketmq.4u8g.cluster 5 47.6 21,420 rocketmq.4u8g.cluster 6 56 25,200 rocketmq.4u8g.cluster 7 64.4 28,980 rocketmq.4u8g.cluster 8 72.8 32,760 rocketmq.4u8g.cluster 9 81.2 36,540 rocketmq.4u8g.cluster 10 89.6 40,320 rocketmq.8u16g.cluster 1 27 12,150 rocketmq.8u16g.cluster 2 43.2 19,440 rocketmq.8u16g.cluster 3 59.4 26,730 rocketmq.8u16g.cluster 4 75.6 34,020 rocketmq.8u16g.cluster 5 91.8 41,310 rocketmq.8u16g.cluster 6 108 48,600 rocketmq.8u16g.cluster 7 124.2 55,890 rocketmq.8u16g.cluster 8 140.4 63,180 rocketmq.8u16g.cluster 9 156.6 70,470 rocketmq.8u16g.cluster 10 172.8 77,760 rocketmq.12u24g.cluster 1 41 18,450 rocketmq.12u24g.cluster 2 65.6 29,520 rocketmq.12u24g.cluster 3 90.2 40,590 rocketmq.12u24g.cluster 4 114.8 51,660 rocketmq.12u24g.cluster 5 139.4 62,730 rocketmq.12u24g.cluster 6 164 73,800 rocketmq.12u24g.cluster 7 188.6 84,870 rocketmq.12u24g.cluster 8 213.2 95,940 rocketmq.12u24g.cluster 9 237.8 107,010 rocketmq.12u24g.cluster 10 262.4 118,080 rocketmq.16u32g.cluster 1 50 22,500 rocketmq.16u32g.cluster 2 80 36,000 rocketmq.16u32g.cluster 3 110 49,500 rocketmq.16u32g.cluster 4 140 63,000 rocketmq.16u32g.cluster 5 170 76,500 rocketmq.16u32g.cluster 6 200 90,000 rocketmq.16u32g.cluster 7 230 103,500 rocketmq.16u32g.cluster 8 260 117,000 rocketmq.16u32g.cluster 9 290 130,500 rocketmq.16u32g.cluster 10 320 144,000 存储空间（元/GB/每代理） 高IO (SAS) 0.0005 0.35 存储空间（元/GB/每代理） 通用型SSD 0.00097 0.7 存储空间（元/GB/每代理） 超高IO (SSD) 0.0014 1 存储空间（元/GB/每代理） 极速型SSD 0.0042 2

准备资源 要求 创建指导 VPC和子网 不同的RocketMQ实例可以重复使用相同的VPC和子网，也可以使用不同的VPC和子网，请根据实际需要进行配置。在创建VPC和子网时应注意如下要求：·创建的VPC与使用的分布式消息服务RocketMQ应在相同的区域。·创建VPC和子网时，如无特殊需求，配置参数使用默认配置即可。 创建VPC和子网的操作指导请参考创建虚拟私有云和子网，若需要在已有VPC上创建和使用新的子网，请参考为虚拟私有云创建新的子网。 安全组 不同的RocketMQ实例可以重复使用相同的安全组，也可以使用不同的安全组，请根据实际需要进行配置。在创建安全组时应注意如下要求：·创建安全组时，“模板”选择“自定义”。·创建安全组后，请保留系统默认添加的入方向“允许安全组内的弹性云服务器彼此通信”规则和出方向“放通全部流量”规则。·使用分布式消息服务RocketMQ必须添加表2所示安全组规则，其他规则请根据实际需要添加。 创建安全组的操作指导请参考创建安全组，为安全组添加规则的操作指导请参考添加安全组规则。

RocketMQ实例是否支持扩容？ 可以扩容。登录RocketMQ控制台，在包周期实例所在行，单击“更多 > 扩容”，即答完成实例的扩容。 消费的最长保留时间是多久？ 一般情况下消息如果未被消费会一直保留，只有被消费后，才会被删除。但是如果设置了过期时间（TTL），则以TTL时间为准。

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

队列监控指标 表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分钟

应用场景 注意：在以下场景需要获取其他云服务资源的访问权限。 分布式消息服务RocketMQ 应用多活功能需要查询分布式消息服务RocketMQ实例信息、同步分布式消息服务RocketMQ数据，因此需要获取访问分布式消息服务RocketMQ服务的权限。 关系数据库MySQL版 应用多活功能需要查询关系数据库MySQL版实例信息，因此需要获取访问关系数据库MySQL版服务的权限。 关系数据库PostgreSQL版 应用多活功能需要查询关系数据库PostgreSQL版实例信息，因此需要获取访问关系数据库PostgreSQL版服务的权限。 数据传输服务DTS 应用多活功能需要通过数据传输服务DTS同步数据库数据，因此需要获取访问数据传输服务DTS服务的权限。 微服务引擎云原生网关 应用多活功能需要向微服务引擎云原生网关推送多活规则，因此需要获取访问微服务引擎云原生网关服务的权限。 微服务引擎注册配置中心 应用多活功能需要微服务引擎注册配置中心管理多活规则，因此需要获取访问微服务引擎注册配置中心服务的权限。 服务内联委托说明 登录系统控制台时，系统会检查当前账号是否已有服务内联委托adtsadmin ，如果不存在则会弹出提示，在您确认授权后，系统自动创建服务内联委托adtsadmin 并授权应用高可用委托授权管理员权限策略。 创建完成后，您可以在IAM控制台的角色管理页面、API或CLI调用ListDelegates 获取委托列表的返回结果中查看已创建的服务内联委托。您还可以登录系统控制台，如果可以正常使用则表示已成功创建服务内联委托。 注意 如果没有adtsadmin服务内联委托权限，可能会因为某个服务权限不足而影响系统功能的正常使用。 请不要自行删除或者修改adtsadmin委托以及应用高可用委托授权管理员权限策略。

分布式消息服务RocketMQ引擎类型CTGMQ引擎调整为白名单特性，更多了解请查看快速入门创建RocketMQ实例引擎类型说明。 调整时间 2024年7月5日 影响范围 所有区域 调整影响 新用户默认不开放CTGMQ引擎订购开通，如需要该特性，请联系技术支持开通后使用。 已购买CTGMQ引擎实例的用户，原实例仍可正常使用，续费、扩容等操作不受影响。

本章节主要介绍分布式消息服务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。

计费模式变更 天翼云分布式消息服务RocketMQ目前支持计费模式变更。

步骤二：测试验证 1. 登录分布式消息服务RabbitMQ控制台。 2. 在左侧导航栏，单击实例列表，选择事件流的源实例。 3. 在队列管理页面，选择源对应队列，点击生产拨测。 4. 在对话框输入想要发送的消息，然后点击发送。 5. 发送消息后返回实例列表，选择事件流的目标实例，进入管理。 6. 在队列管理页面，选择目标对应队列，点击消费拨测，查询目标队列对应的消息。 7. 查看查询到消息体与消息属性是否与预期一致，如图2所示。 图2 在分布式消息服务RabbitMQ管理控制台中查看消息详情

本节介绍了如何查看分布式消息服务RabbitMQ产品实例。 背景信息 RabbitMQ实例是指使用RabbitMQ消息队列的具体应用场景或示例。这些实例可以是各种不同的系统、应用或业务流程，通过使用RabbitMQ来实现消息的传递和处理。 例如，一个订单处理系统可以使用RabbitMQ来处理订单信息的传递和处理。当有新的订单生成时，订单信息可以被发送到RabbitMQ的消息队列中，然后由不同的消费者来处理这些订单信息，如库存管理、支付处理和物流跟踪等。 另一个例子是日志收集系统，通过使用RabbitMQ作为消息中间件，可以将分布式系统中的日志消息发送到消息队列中，然后由日志收集器消费者来处理和存储这些日志消息。这样可以实现日志的集中管理和分析，方便故障排查和系统性能监控。 其他常见的RabbitMQ实例包括异步任务处理、事件驱动架构、分布式系统通信等。通过使用RabbitMQ，这些实例可以实现系统组件之间的解耦、提高系统的可伸缩性和可靠性，从而更好地满足复杂应用场景的需求。 实例列表 1、进入控制台查看已购买的实例列表，若列表为空，可点击右上角【创建实例】进入购买页面，创建实例详情见具体操作步骤。 2、支持按照实例ID查询，输入查询内容，点击【查询】按钮即可展示需要的实例数据。 3、查看实例基本信息，包括实例ID、规格、VPC、计费模式、创建时间、到期时间、状态。其中状态说明见下文。 运行状态 （1）登录管理控制台。 （2）进入RabbitMQ管理控制台。 （3）当前页面会列出所购买的RabbitMQ实例，并查看状态，状态说明如下 状态 说明 运行中 RabbitMQ实例正常运行状态。在这个状态的实例可以运行您的业务。 已关闭 RabbitMQ实例处于故障的状态。 变更中 RabbitMQ实例正在进行规格变更操作。 变更失败 RabbitMQ实例处于规格变更失败状态。 暂停 RabbitMQ专享版实例处于已冻结状态，用户可以在“更多”中续费开启冻结的RabbitMQ实例。 注销 RabbitMQ实例已经过期并关闭，需要重新购买实例。

分类 服务 命名空间 维度 监控指标参考文档 企业中间件 分布式消息服务 SYS.DMS 请参考右侧相关文档链接页面。

介绍分布式消息服务RabbitMQ死信和TTL功能。 死信 称为死信的信息，需要如下几个条件： 消息被消费者拒绝（通过basic.reject 或者 back.nack），并且设置 requeuefalse。 消息过期，队列设置了TTL（Time To Live）时间并且消息过期。 超过了队列的长度限制消息被丢弃。 为队列配置死信交换机，并在申明队列时指定“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 RabbitMQ可以对消息和队列设置TTL. 目前有两种方法可以设置。第一种方法是通过队列属性设置，队列中所有消息都有相同的过期时间。第二种方法是对消息进行单独设置，每条消息TTL可以不同。如果上述两种方法同时使用，则消息的过期时间以两者之间TTL较小的那个数值为准。消息在队列的生存时间一旦超过设置的TTL值，就称为dead message， 消费者将无法再收到该消息。 设置队列TTL 通过队列属性设置消息TTL的方法是在queue.declare方法中加入xmessagettl参数，单位为ms. 以下示例演示在Java客户端设置队列TTL。 Map argss new HashMap (); argss.put("xmessagettl",6000); channel.queueDeclare(queueName, durable, exclusive, autoDelete, argss);

本节介绍了分布式消息服务RabbitMQ产品常见操作类问题。 无法被路由的消息，去了哪里？ 如果没有任何设置，无法路由的消息会被直接丢弃。 无法路由的情况：Routing key不正确。 解决方案： 1.使用mandatorytrue配合ReturnListener，实现消息回发。 2.声明交换机时，指定备份交换机。 多个消费者监听一个队列时，消息如何分发？ 1.RoundRobin（轮询） 默认的策略，消费者轮流、平均地收到消息。 2.Fair dispatch（公平分发） 如果要实现根据消费者的处理能力来分发消息，给空闲地消费者发送更多消息，可以用basicQos(int prefetchcount)来设置。prefetchcount含义：当消费者有多条消息没有响应ACK时，不再给这个消费者发送消息。 消息在什么时候会变成Dead Letter(死信)？ 1.消息被拒绝并且没有设置重新入队：(NACK Reject ) && requeue false 2.消息过期(消息或者队列的TTL设置) 3.消息堆积，并且队列达到最大长度，先入队的消息编程DL。 解决方案：可以在声明队列时，指定一个Dead Letter Exchange，来实现Dead Letter的转发，保证消息不会丢失。 如何进行消息持久化？ 所谓持久化，就是RabbitMQ将内存中的数据（比如交换机、队列、消息等）固化到磁盘，以防止异常情况的发生时造成数据丢失。 持久化分类 说明 交换机持久化 在创建Exchange时设置durable参数参数。channel.exchangeDeclare(EXCHANGENAME, "direct", true); 队列持久化 同样也是设置设置durable参数。持久化的队列会存盘，在服务器重启的时候可以保证不丢失相关信息。channel.queueDeclare(QUEUENAME, true, false, false, null); 消息持久化 即使交换机、队列持久化不会因为重启丢失，但是存储在队列中的消息仍然会丢失。解决的办法就是设置消息的投递模式为2，即代表持久化(JAVA)。理论上，可以将所有的消息都设置为持久化，但是这会严重影响RabbitMQ性能，因为写入到磁盘的速度可比写入到内存的速度慢非常多。因此，在选择是否要持久化消息时，需要在可靠性和吞吐量之间做一个权衡。

高可靠性 分布式消息服务RabbitMQ使用了持久化、传输确认、发布确认等机制来保证可靠性。 持久化 消息持久化：默认情况下，RabbitMQ将消息存储在内存中，这意味着如果RabbitMQ服务器关闭或发生故障，未被消费的消息将会丢失。为了解决这个问题，可以将消息设置为持久化的。当消息被标记为持久化时，RabbitMQ会将消息存储到磁盘上的文件中，以确保消息在服务器重启后仍然可用。 队列持久化：除了消息持久化外，还可以将队列标记为持久化。当队列被标记为持久化时，RabbitMQ会将队列的元数据和消息都存储到磁盘上的文件中。这样，在服务器重启后，队列和其中的消息将会被重新创建。 交换机持久化：交换机也可以被标记为持久化。当交换机被标记为持久化时，RabbitMQ会将交换机的元数据存储到磁盘上的文件中。然而，交换机本身并不存储消息，因此即使交换机持久化了，如果没有持久化的队列与其绑定，未被消费的消息仍然会丢失。 持久化模式：在RabbitMQ中，可以选择将消息和队列都标记为持久化，或者只将其中一项标记为持久化。通过将消息和队列都标记为持久化，可以最大程度地确保消息的安全性。但是，需要注意的是，将所有消息都持久化可能会导致性能下降。 传输确认 发布确认模式（Publish Confirm）：当生产者发送消息给RabbitMQ后，可以通过设置“Confirm模式”来确保消息已被RabbitMQ接收和处理。可以使用事务或者确认模式来实现。 事务模式：在事务模式下，生产者可以将消息发送到RabbitMQ，并进行事务提交操作。如果发送成功，则事务会被提交，消息会被RabbitMQ接收和处理，否则事务会被回滚。 确认模式：在确认模式下，生产者将消息发送到RabbitMQ，并等待RabbitMQ发送一个确认消息给生产者来表示该消息已经被成功接收和处理。 多个消息的批量确认：可以以批量的方式进行消息的确认，即同时确认多个消息，而不是逐个确认。 异步确认：可以使用异步的方式进行确认，即发送消息后不需要等待确认消息的返回，而是通过回调函数来处理确认结果。 应答超时设置：为了避免消息发送失败或者长时间无响应造成的阻塞，可以设置应答超时时间，超过该时间还未收到确认消息，则认为消息发送失败。 发布确认 RabbitMQ发布确认机制是一个确保消息在发送到队列之后被成功接收的机制。它提供了两种发布确认模式：简单模式和批量模式。 简单模式： 在发送每条消息之后，生产者会等待来自RabbitMQ的确认回复。 如果RabbitMQ成功接收到消息并将其存储在队列中，它会返回一个确认回复给生产者。 如果由于某种原因消息未能成功发送到队列，RabbitMQ将返回一个拒绝回复给生产者。 生产者可以根据具体情况来处理确认和拒绝回复。 批量模式： 在发送一批消息后，生产者会等待来自RabbitMQ的一个确认回复。 如果RabbitMQ成功接收到批量消息并将它们存储在队列中，它会返回一个确认回复给生产者。 如果其中任何一条消息未能成功发送到队列，RabbitMQ将返回一个拒绝回复给生产者，并且不会存储整个批量消息。 生产者可以根据具体情况来处理确认和拒绝回复。

应用进程、消费组、消费者实例的关系 消费组可以有多个消费者实例。 同一进程，同一个消费组不允许有相同的消费者实例。 不同进程，不能创建相同消费者实例，可能产生两个实例分配到相同的队列，部分队列却没有消费的情况。 不同进程，不能创建相同消费者实例，如上图中的实例A，两个实例均连到Q1跟Q2，但Q3与Q4并无消费。 应用在创建消费者实例时，指定消费者实例名，应用需要保证不同的进程间，同一消费组不能有相同的实例名。或者应用在创建消费者实例时，不指定实例名，RocketMQ会创建唯一的实例名(JAVA SDK)，规则是：groupNameippid线程iduuid。 同组Consumer订阅关系一致 RocketMQ 里的一个 Consumer Group 代表一个 Consumer 群组。对于大多数分布式应用来说，一个 Consumer Group 下通常会有多个 Consumer 实例。订阅关系一致指的是同一个 Consumer Group 下所有 Consumer 实例的处理逻辑必须完全一致，一旦订阅关系不一致，消息消费的逻辑就会混乱，甚至导致消息丢失。 由于 RocketMQ 的订阅关系主要由 Topic+Tag 共同组成，因此，保持订阅关系一致意味着同一个 Consumer group 下所有的实例需在以下两方面均保持一致： 1.订阅的 Topic 必须一致。 2.订阅的 Topic 中的 Tag 必须一致。

产品服务等级协议请查看： 分布式消息服务RocketMQ服务等级协议