本章节主要介绍如何开启分布式消息服务RabbitMQ实例插件。 RabbitMQ实例创建后，支持开启如下插件，实例创建后默认都是关闭状态。 RabbitMQ插件功能可用于测试和迁移业务等场景，不建议用于生产业务。详情请参考约束与限制。 表1 支持修改状态的实例插件 插件名称 功能描述 端口号 rabbitmqamqp10 表示实例是否支持AMQP1.0协议。 rabbitmqdelayedmessageexchange 表示实例是否开启消息延迟功能。插件延迟时间存在1%左右的误差，可能提前或者推迟发送消息给消费者。 rabbitmqfederation 表示实例是否开启消息同步功能。 rabbitmqsharding 表示实例是否开启消息分片功能。 rabbitmqshovel 表示实例是否开启消息迁移功能。 rabbitmqtracing 表示实例是否开启消息追踪功能。 rabbitmqmqtt 表示实例是否支持MQTT协议（TCP方式）。 1883 rabbitmqwebmqtt 表示实例是否支持MQTT协议（WebSocket方式）。 15675 rabbitmqstomp 表示实例是否支持STOMP协议（TCP方式）。 61613 rabbitmqwebstomp 表示实例是否支持STOMP协议（WebSocket方式）。 15674 rabbitmqconsistenthashexchange 表示实例是否支持xconsistenthash。 说明 插件端口号不支持修改。

本文为您介绍分布式消息服务MQTT的操作指南设备轨迹。 分布式消息服务MQTT支持按clientId按天维度查询设备轨迹，以帮助排查设备在线问题和定位问题的原因。通过设备轨迹查询，您可以获取设备的连接历史和动作说明，以便更好地了解设备的行为和状态。 操作步骤 1、 天翼云官网点击控制中心，选择产品分布式消息服务MQTT。 2、 登录分布式消息服务MQTT控制台，点击右上角地域选择对应资源池。 3、 进入实例列表，点击【管理】按钮进入管理菜单。 4、 进入设备轨迹菜单页面，输入Client ID和时间范围，点击搜索按钮。 5、 展示设备各时间节点的动作信息。 查询结果 字段 说明 时间 动作发生的日期时间 Client ID 设备id 动作 connect：建立连接 subscribed：主题订阅 resumed：会话恢复 disconnect：连接断开 discarded：会话丢弃，cleanSessiontrue客户端连接如果服务端中已存在该客户端的会话，丢弃旧的会话 takeovered：会话接管，cleanSessionfalse客户端连接如果服务端中已存在该客户端的会话，旧的会话被该连接接管

本文为您介绍分布式消息服务MQTT的创建实例内容。 实例介绍 MQTT实例订购支持用户自定义规格和自定义特性，采用物理隔离的方式部署。租户独占MQTT实例，可根据业务需要可定制相应规格的MQTT实例。在新的资源池节点上，还支持选择主机类型和存储规格等丰富用户选项。 操作步骤 1、在产品详情页点击立即开通按钮，或者进入消息管理控制台订购实例，进入订购分布式消息MQTT页面。 2、 订购实例，注意选择产品规格。 （1）填写实例名称，长度4~40个字符，大小写字母开头，只能包含大小写字母、数字及分隔符()。 （2）选择计费模式：包年包月/按需计费，两种模式说明参见计费模式。 （3）购买时长按照计费模式选择变化： 计费模式为包年包月，可选择购买时长16个月、13年。该模式提供自动续期功能，勾选后可以自动续期购买时长：16个月、13年。 计费模式为按需计费，则该选项隐藏无需选择。 （4）部署方式有单可用区和多可用区两个选项，目前仅支持单可用区和3可用区部署,单可用区部署请选中任意一个AZ；多可用区部署请选中3个AZ，系统会自动将Broker节点平均分配至各可用区。 （5）设置节点数，可输入3~16个。MQTT 的节点数是指MQTT 集群中的节点数量。在MQTT 集群中，可以有多个节点组成一个集群，每个节点都是一个独立的MQTT 服务器实例。 （6）下拉选择主机类型，目前提供计算增强型。计算增强型云主机独享宿主机的CPU资源，实例间无CPU争抢，并且没有进行资源超配，同时搭载全新网络加速引擎，实现接近物理服务器的强劲稳定性能。 （7）选择实例规格，分布式消息服务MQTT提供计算增强型多种云主机规格，各规格详细说明参见弹性云主机规格。 （8）选择已有虚拟私有云，若无虚拟私有云，点击创建跳转到虚拟私有云页面新增，了解更多内容参见虚拟私有云。 （9）选择已有子网，若无子网，点击创建跳转到子网页面新增，了解更多内容参见虚拟私有云子网管理 创建子网。 （10）选择已有安全组，若无安全组，点击创建跳转到安全组页面新增，了解更多内容参见虚拟私有云安全组 创建安全组。 3、 填写完上述信息后，单击“下一步”，进入费用确认页面。 4、 确认实例信息无误后，提交请求。 5、 在实例列表页面，查看MQTT实例是否创建成功。创建实例大约需要3到15分钟，此时实例状态为“创建中”。

本文为您介绍分布式消息服务MQTT的API消息发送。 POST ContentType：application/json 请求体json参数说明： 参数名 参数类型 是否必填 参数描述 prodInstId String 是 实例ID mqttTopic String 是 MQTT主题 payload String 是 消息内容 返回参数说明： 参数名 参数类型 参数描述 message String 描述状态 statusCode Integer 800成功 其他失败 成功 { "message": "success","statusCode": "800"} 失败 {"returnObj": null,"message": "error","statusCode": "900"}

创建联系人组 进入分布式消息服务MQTT管理控制台，在实例列表页点击管理进入实例详情页，左侧菜单点击告警管理 点击通知组菜单，右侧点击新建联系人组，输入联系人信息信息，点击保存 创建通知策略 进入分布式消息服务MQTT管理控制台，在实例列表页点击管理进入实例详情页，左侧菜单点击告警管理 点击通知策略菜单，右侧点击创建通知策略，输入信息，点击确认 创建告警规则 进入分布式消息服务MQTT管理控制台，在实例列表页点击管理进入实例详情页，左侧菜单点击告警管理 点击告警规则菜单，右侧点击创建告警规则，选择告警指标，输入告警条件、告警内容等信息，点击保存 成为第一个赞同者

顺序消息是分布式消息服务RocketMQ版提供的一种严格按照顺序来发布和消费的消息类型。 顺序消息分为全局顺序消息和分区顺序消息： 全局顺序消息：对于指定的一个Topic，将队列数量设置为1，这个队列内所有消息按照严格的先入先出FIFO（First In First Out）的顺序进行发布和订阅。 分区顺序消息：对于指定的一个Topic，同一个队列内的消息按照严格的FIFO顺序进行发布和订阅。生产者指定分区选择算法，保证需要按顺序消费的消息被分配到同一个队列。 全局顺序消息和分区顺序消息的区别仅为队列数量不同，代码没有区别。 收发消息前，请参考收集连接信息收集RocketMQ所需的连接信息。 准备环境 开源的Java客户端支持连接分布式消息服务RocketMQ版，推荐使用的客户端版本为4.9.7。 通过以下任意一种方式引入依赖： 1. 使用Maven方式引入依赖。 org.apache.rocketmq rocketmqclient 4.9.7 org.apache.rocketmq rocketmqacl 4.9.7 2. 点击下载依赖JAR包：rocketmqall4.9.7binrelease.zip 发送顺序消息 参考如下示例代码 import org.apache.rocketmq.acl.common.AclClientRPCHook; import org.apache.rocketmq.acl.common.SessionCredentials; import org.apache.rocketmq.client.producer.DefaultMQProducer; import org.apache.rocketmq.client.producer.SendResult; import org.apache.rocketmq.common.message.Message; import org.apache.rocketmq.remoting.RPCHook; import org.apache.rocketmq.remoting.common.RemotingHelper; public class ProducerFifoExample { private static RPCHook getAclRPCHook() { return new AclClientRPCHook(new SessionCredentials( "accessKey", // 分布式消息服务RocketMQ控制台用户管理菜单中创建的用户ID "accessSecret" // 分布式消息服务RocketMQ控制台用户管理菜单中创建的密钥 )); } public static void main(String[] args) throws Exception { / 创建Producer，如果想开启消息轨迹，可以按照如下方式创建： DefaultMQProducer producer new DefaultMQProducer("YOUR GROUP ID", getAclRPCHook(), true, null); / DefaultMQProducer producer new DefaultMQProducer("YOUR GROUP ID", getAclRPCHook()); // 填入控制台NAMESRV接入点地址 producer.setNamesrvAddr("XXX:xxx"); ; // 如果需要开启SSL，请增加此行代码 producer.start(); for (int i 0; i { // 选择适合自己的分区选择算法，保证同一个参数得到的结果相同。 Integer id (Integer) arg; int index id % mqs.size(); return mqs.get(index); }, orderId); System.out.printf("%s%n", sendResult); } catch (Exception e) { e.printStackTrace(); } } producer.shutdown(); } } 注意 上述代码中，相同id的消息需要保证顺序，不同id的消息不需要保证顺序，所以在分区选择算法中以“id/队列个数的余数”作为消息发送的队列。

本文介绍分布式消息服务MQTT操作类常见问题 终端设备一直处于断线状态？ 检查终端客户端端使用是否进行了重连机制。 连接异常断开？ （1）不同的客户端使用相同的Client ID； （2） 报文是否超过最大限制； （3）权限不匹配。 断线重连收不到消息？ （1）对于cleanSessiontrue的客户端，断线重连后需要重新主题订阅； （2）对于cleanSessionfalse的客户端，断线在2h时间范围内重新成功无需进行主题订购，超过也需主题重新订阅。 离线消息缺失？ 对于clean sessionfalse的客户端在未超出会话失效期断线重连后可接收Qos>0的离线消息，离线消息限制不超过10条。 Broker连接数为0？ MQTT Broker节点宕机重连，客户端重连至其他节点，正常现象。 产品订购时可选资源池节点不一致？ 已上线资源池节点的剩余容量达到一定比例后，为确保老客户权益，将不再面向新客户开放，产品订购时的可选资源节点范围以实际为准。 为什么控制台显示的订阅关系数比实际使用的高很多？ 当cleanSession设置为false时，客户端离线后订阅关系也会一直保留，不会被清理。通过设置cleanSession为false，可以确保在客户端离线时保留订阅关系，这对于一些需要持久化订阅关系的应用场景非常有用，例如设备断开连接后重新连接时仍然需要保持之前的订阅状态。 需要注意的是，当cleanSession设置为false时，MQTT Broker需要维护客户端的会话状态，这可能会增加服务器的负担。因此，在设计和配置MQTT应用时，需要权衡清理会话和保留会话的需求，并根据实际情况进行设置。

云服务分类 云服务名称 产品控制台创建资源时是否支持绑定标签 产品控制台列表是否支持绑定和解绑标签 标签字符长度限制 标签字符内容限制 单实例默认可绑定标签个数 计算 弹性云主机 是 是 128位 首尾不包含空格 50 计算 GPU云主机 是 是 128位 首尾不包含空格 50 计算 物理机 是 是 128位 首尾不包含空格 50 计算 镜像服务 是 是 128位 首尾不包含空格 50 计算 弹性伸缩服务 是 是 128位 首尾不包含空格 50 计算 云主机快照 是 是 128位 首尾不包含空格 50 计算 SSH秘钥对 是 是 128位 首尾不包含空格 50 存储 云硬盘 是 是 128位 开头不包含空格 50 存储 弹性文件服务 否 是 128位 首尾不包含空格 50 存储 对象存储 是 是 128位 首尾不包含空格 50 存储 并行文件服务HPFS 是 是 128位 首尾不包含空格 50 存储 海量文件服务OceanFS 是 是 128位 首尾不包含空格 50 存储 云硬盘备份 是 是 128位 开头不包含空格 50 存储 云主机备份 是 是 128位 开头不包含空格 50 网络 弹性负载均衡 是 是 128位 首尾不包含空格 50 网络 共享流量包 否 是 128位 首尾不包含空格 50 网络 VPC终端节点 是 是 128位 首尾不包含空格 50 网络 NAT网关 是 是 128位 首尾不包含空格 50 网络 网关负载均衡 是 是 128位 首尾不包含空格 50 网络 内网DNS 否 是 128位 首尾不包含空格 50 网络 弹性IP 否 是 128位 首尾不包含空格 50 网络 共享带宽 否 是 128位 首尾不包含空格 50 网络 虚拟私有云 否 是 128位 首尾不包含空格 50 网络 流量镜像 否 是 128位 首尾不包含空格 50 网络 对等连接 是 是 128位 首尾不包含空格 50 网络 云间高速（标准版） 否 是 128位 首尾不包含空格 50 网络 VPN连接 否 是 128位 首尾不包含空格 50 网络 云专线CDA 是 是 128位 首尾不包含空格 50 专属云 专属云（计算独享型） 是 是 128位 首尾不包括空格 50 云原生 云容器引擎 是 是 128位 首尾不包含空格 50 云原生 容器镜像服务 否 是 128位 首尾不包含空格 50 云原生 云日志服务 否 是 128位 首尾不包含空格 50 云原生 应用性能监控 否 是 128位 首尾不包含空格 20 云原生 微服务云应用平台MSAP 否 是 128位 首尾不包含空格 50 云原生 微服务引擎API网关 否 是 128位 首尾不包含空格 20 云原生 微服务引擎微服务治理 否 是 128位 首尾不包含空格 20 云原生 微服务引擎注册配置中心 否 是 128位 首尾不包含空格 20 云原生 服务网格 否 是 128位 首尾不包含空格 50 云原生 分布式缓存服务Redis版 是 是 128位 首尾不包含空格 50 云原生 分布式消息队列RocketMQ 是 是 128位 首尾不包含空格 50 云原生 分布式消息队列RabbitMQ 是 是 128位 首尾不包含空格 50 云原生 分布式消息队列Kafka 是 是 128位 首尾不包含空格 50 云原生 分布式消息队列MQTT 是 是 128位 首尾不包含空格 50 云原生 弹性容器实例ECI 否 是 128位 首尾不包含空格 50 云原生 分布式容器云平台CCE ONE 是 是 128位 首尾不包含空格 20 云原生 Serverless容器引擎 是 是 128位 首尾不包含空格 50 云原生 函数计算 否 是 128位 首尾不包含空格 50 安全及管理 Web应用防火墙（原生版） 否 是 无限制 首尾不包含空格 50 安全及管理 服务器安全卫士（原生版） 否 是 128位 首尾不包含空格 10 安全及管理 云等保专区 否 是 128位 首尾不包含空格 50 安全及管理 数据库审计 否 是 128位 首尾不包含空格 10 安全及管理 云堡垒机（原生版） 否 是 128位 首尾不包含空格 10 安全及管理 日志审计（原生版） 否 是 128位 首尾不包含空格 10 安全及管理 秘钥管理 否 是 128位 首尾不包含空格 10 安全及管理 云密评专区 否 是 128位 首尾不包含空格 10 数据库 文档数据库服务 是 是 128位 首尾不包含空格 50 数据库 分布式关系型数据库 是 是 128位 首尾不包含空格 10 数据库 关系数据库PostgreSQL版 是 是 128位 首尾不包含空格 50 数据库 关系数据库MySQL版 是 是 128位 首尾不包含空格 50 数据库 云数据库ClickHouse版 是 是 128位 首尾不包含空格 50 数据库 关系数据库SQL Server版 是 是 128位 首尾不包含空格 50 数据库 数据传输服务DTS 否 是 128位 首尾不包含空格 50

本文为您介绍分布式消息服务MQTT的快速入门创建实例。 实例介绍 MQTT实例订购支持用户自定义规格和自定义特性，采用物理隔离的方式部署。租户独占MQTT实例，可根据业务需要可定制相应规格的MQTT实例。在新的资源池节点上，还支持选择主机类型和存储规格等丰富用户选项。 操作步骤 1、在产品详情页点击立即开通按钮，或者进入消息管理控制台创建实例，进入订购分布式消息MQTT页面。 2、 创建实例，注意选择产品规格。 （1）填写实例名称，长度4~40个字符，大小写字母开头，只能包含大小写字母、数字及分隔符()。 （2）选择计费模式：包年包月/按需计费，两种模式说明参见计费模式。 （3）购买时长按照计费模式选择变化： 计费模式为包年包月，可选择购买时长16个月、13年。该模式提供自动续期功能，勾选后可以自动续期购买时长：16个月、13年。 计费模式为按需计费，则该选项隐藏无需选择。 （4）部署方式有单可用区和多可用区两个选项，目前仅支持单可用区和3可用区部署,单可用区部署请选中任意一个AZ；多可用区部署请选中3个AZ，系统会自动将Broker节点平均分配至各可用区。 （5）设置节点数，可选择3/5/7/9。MQTT 的节点数是指MQTT 集群中的节点数量。在MQTT 集群中，可以有多个节点组成一个集群，每个节点都是一个独立的MQTT 服务器实例。 （6）下拉选择主机类型，可选择通用型和计算增强型。通用型云主机共享宿主机的CPU资源，主要提供基本水平的vCPU性能、平衡的计算、内存和网络资源，具有较高性价比，支持通用的业务运行。计算增强型云主机独享宿主机的CPU资源，实例间无CPU争抢，并且没有进行资源超配，同时搭载全新网络加速引擎，实现接近物理服务器的强劲稳定性能。 （7）选择实例规格，分布式消息服务MQTT提供通用型和计算增强型各3类规格，各规格详细说明参见弹性云主机规格。 （8）选择存储空间，包括磁盘类型和空间。 磁盘类型提供高IO/普通IO/超高IO三类。普通IO适用于大容量、读写速率中等、事务性处理较少的应用场景。高IO：适用于主流的高性能、高可靠应用场景。超高IO：适用于超高IOPS、超大带宽需求的读写密集型应用场景。了解更多磁盘类型说明参见云硬盘规格。 磁盘空间以100G起步，可以以100倍数增加磁盘空间。 （9）选择已有虚拟私有云，若无虚拟私有云，点击创建跳转到虚拟私有云页面新增，了解更多内容参见虚拟私有云。 （10）选择已有子网，若无子网，点击创建跳转到子网页面新增，了解更多内容参见虚拟私有云子网管理 创建子网。 （11）选择已有安全组，若无安全组，点击创建跳转到安全组页面新增，了解更多内容参见虚拟私有云安全组 创建安全组。 3、 填写完上述信息后，单击“下一步”，进入费用确认页面。 4、 确认实例信息无误后，提交请求。 5、 在实例列表页面，查看MQTT实例是否创建成功。创建实例大约需要3到15分钟，此时实例状态为“创建中”。

消息重试 对于有序消息：有序消息不能跳跃签收，当消费者消费消息失败后，消息队列RocketMQ会自动不断进行消息重试 （每次间隔时间为1秒），此时应用会出现消息消费被阻塞的情况。因此建议使用有序消息时，务必保证应用能够及时监控并处理消费失败的情况，避免阻塞现象的发生。 对于无序消息：消息队列RocketMQ默认允许每条消息最多重试16次。 每次重试的间隔时间如下： 第几次重试 与上次重试的间隔时间 1 10秒 2 30秒 3 1分钟 4 2分钟 5 3分钟 6 4分钟 7 5分钟 8 6分钟 9 7分钟 10 8分钟 11 9分钟 12 10分钟 13 20分钟 14 30分钟 15 1小时 16 2小时 如果消息重试16次后仍然失败，消息将不再投递。如果严格按照上述重试时间间隔计算，某条消息在一直消费失败的前提下，将会在接下来的4小时46分钟之内进行16次重试，超过这个时间范围消息将不再重试投递。 消息过滤 消费者订阅了某个Topic后，消息队列RocketMQ会将该主题中的所有消息投递给消费者。若消费者只需要关注部分消息，可通过设置过滤条件在消息队列RocketMQ版服务端进行过滤，只获取到需要关注的消息子集，避免接收到大量无效的消息。 消息过滤主要通过以下几个关键流程实现： 生产者：生产者在初始化消息时预先为消息设置一些属性和标签，用于后续消费时指定过滤目标。 消费者：消费者在初始化及后续消费流程中向服务端上报需要订阅指定主题的哪些消息，即过滤条件。 服务端：消息队列RocketMQ服务端根据消费者上报的过滤条件的表达式进行匹配，将符合条件的消息投递给消费者进行消费。 消息队列RocketMQ支持两种过滤方式： 通过Tag进行过滤：生产者在发送消息时，设置消息的Tag标签，消费者通过 Tag标签指定需要消费的信息。 通过SQL属性过滤：通过生产者为消息设置的属性（Key）及属性值（Value）进行匹配。生产者在发送消息时可设置多个属性，消费者订阅时可设置SQL语法的过滤表达式过滤多个属性。

顺序消息是分布式消息服务RocketMQ版提供的一种严格按照顺序来发布和消费的消息类型。 顺序消息分为全局顺序消息和分区顺序消息： 全局顺序消息：对于指定的一个Topic，将队列数量设置为1，这个队列内所有消息按照严格的先入先出FIFO（First In First Out）的顺序进行发布和订阅。 分区顺序消息：对于指定的一个Topic，同一个队列内的消息按照严格的FIFO顺序进行发布和订阅。生产者指定分区选择算法，保证需要按顺序消费的消息被分配到同一个队列。 全局顺序消息和分区顺序消息的区别仅为队列数量不同，代码没有区别。 收发消息前，请参考收集连接信息收集RocketMQ所需的连接信息。 准备环境 1. 在命令行输入python，检查是否已安装Python。得到如下回显，说明Python已安装。 PS C:> python Python 3.9.9 (tags/v3.9.9:ccb0e6a, Nov 15 2021, 18:08:50) [MSC v.1929 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. 如果未安装Python，请使用以下命令安装： pip install rocketmqclientpython 2. 安装librocketmq库和rocketmqclientpython。 说明 建议下载rocketmqclientcpp2.2.0，获取librocketmq库。 3. 将librocketmq.so添加到系统动态库搜索路径。 1. 查找librocketmq.so的路径。 find / name librocketmq.so 2. 将librocketmq.so添加到系统动态库搜索路径。 ln s /查找到的librocketmq.so路径/librocketmq.so /usr/lib sudo ldconfig 以下示例代码中的参数说明如下，请参考收集连接信息获取参数值。 GROUP：表示消费组名称。 ENDPOINT：表示实例连接地址和端口。 TOPIC：表示Topic名称。

配置项 操作 示例 触发器类型 选择 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

介绍分布式消息服务MQTT实例列表内容。 操作说明 1、 进入控制台查看已购买的实例列表，若列表为空，可点击右上角【订购实例】进入购买页面，创建实例详情见具体操作步骤。 2、 支持按照实例名称查询，输入查询内容，点击【查询】按钮即可展示需要的实例数据。 3、 查看实例基本信息，包括实例ID、规格、计费模式、创建时间、到期时间、状态。其中状态说明见下文。 运行状态 1、 登录管理控制台。 2、 进入MQTT管理控制台。 3、 当前页面会列出所购买的MQTT实例，并查看状态，状态说明如下 状态 说明 运行中 MQTT实例正常运行状态。在这个状态的实例可以运行您的业务。 已关闭 MQTT实例处于故障的状态。 变更中 MQTT实例正在进行规格变更操作。 变更失败 MQTT实例处于规格变更失败状态。 暂停 MQTT实例处于已冻结状态，用户可以在“更多”中续费开启冻结的MQTT实例。 注销 MQTT实例已经过期并关闭，需要重新购买实例。 回收站 1、实例退订后，在回收站可查看已退订实例。 2、回收站实例销毁。 点击回收站实例列表“销毁”，进入实例销毁页面，提交订单。

为了让更多客户享受到分布式消息MQTT产品服务，我们致力于为客户提供更具竞争力的价格，并持续提升服务质量。 分布式消息服务MQTT自9月25日起开始启用新资费计价，老资费通用型同规格对比新费用降幅达78%84%。 实例规格参数 实例价格费用明细 降幅 实例规格参数 调整前 调整后 降幅 实例规格参数 单价（元/节点/月） 总费用（元/月） 单价（元/节点/月） 总费用（元/月） 降幅 s7.xlarge.4，4vCPUs 16GiB，3节点 4548 13644 720 2160 84% s7.2xlarge.4，8vCPUs 32GiB，3节点 8288 24864 1620 4860 80% s7.4xlarge.4，16vCPUs 64GiB，3节点 14976 44928 3240 9720 78% 同时新增包年折扣优惠，即日起订购分布式消息服务MQTT产品享受1年83折 优惠，11月将陆续开放2年7折，3年5折优惠选项，具体开放时间敬请关注产品公告。 此外，为保障更优的性能，11月计划上架Intel计算增强型规格，原通用型规格将调整为白名单特性，原老客户实例续订不受影响，新用户和新实例订购推荐开通计算增强型规格产品。

本文为您介绍分布式消息服务MQTT的API设备客户端查设备连接信息。 GET URI参数说明： 参数名 参数类型 是否必填 参数描述 prodInstId String 是 实例ID clientId String 是 设备ID 返回参数说明： 参数名 参数类型 参数描述 statusCode Integer 800成功 其他失败 message String 描述状态 returnObj Object 返回对象 returnObj.connectedat String 连接时间 returnObj.sendmsg Integer 发送消息数量 returnObj.disconnectedat String 断开时间 returnObj.recvmsg Integer 接收消息数量 returnObj.protoname String 协议名称 returnObj.connected Boolean 是否在线 returnObj.username String 用户名 returnObj.cleanstart Boolean 持久化会话 返回示例：(800)成功 {"statusCode": 800,"message": "success","returnObj": [{"connectedat": "20220824 16:28:14","sendmsg": 181,"subscriptionscnt": 1,"disconnectedat": "20220824 16:47:30","recvmsg": 0,"protoname": "MQTT","connected": false,"username": "test","cleanstart": false}]} 返回示例：失败 {"returnObj": null,"message": "error","statusCode": "900"}

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

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

介绍分布式消息服务RabbitMQ仲裁队列功能。 使用场景 仲裁队列（Quorum Queue）是基于Raft一致性协议实现的一种新型的分布式消息队列，针对RabbitMQ的镜像模式设计。仲裁队列中的消息需要有集群中过半节点同意确认后，才会写入到队列中。 仲裁队列与镜像队列的差异 使用镜像队列，当生产者发送一条消息，主队列会将消息同步给镜像队列，所有的镜像队列都保存消息后，主队列才会向生产者发送确认。 仲裁队列的算法是基于Raft共识算法的一个实现。仲裁队列包含一个主副本和多个从副本，当生产者向主副本发送消息时，主副本会将消息同步给从副本，当超过半数的副本保存消息后，主副本才会向生产者发送确认。并且，主副本的选举也需要超过半数的副本同意，这会避免出现网络分区时队列元数据不一致。所以仲裁队列有更高的一致性。 配置方法 在声明队列时，将队列的“xqueuetype”参数设置为“quorum”。 以下为java示例 Map arguments newHashMap<>(); arguments.put("xqueuetype", "quorum"); channel.queueDeclare("testquorumqueue", true, false, false, arguments); 设置仲裁队列的长度 通过设置队列属性的方式可以限制仲裁队列的长度和在内存中保存的长度。 xmaxlength：仲裁队列的最大消息数。如果超过则丢弃消息，或者发送到死信交换器。 xmaxlengthbytes：仲裁队列的最大总消息大小（字节数）。如果超过则丢弃消息，或者发送到死信交换器。 xmaxinmemorylength：限制仲裁队列的内存中最大消息数量。 xmaxinmemorybytes：限制仲裁队列的内存中的最大总消息大小（字节数）。

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

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

收取普通消息 include include include "rocketmq/DefaultMQPushConsumer.h" using namespace rocketmq; class ConcurrentMessageListener : public MessageListenerConcurrently { public: ConsumeStatus consumeMessage(const std::vector &msgs) { for (auto item msgs.begin(); item ! msgs.end(); item++) { std::cout getTopic() getMsgId() setNamesrvAddr("your access point"); consumer>setSessionCredentials("ak", "sk"); ConcurrentMessageListener messageListener new ConcurrentMessageListener(); consumer>subscribe("topicname", "tag"); consumer>registerMessageListener(messageListener); consumer>start(); std::thisthread::sleepfor(std::chrono::seconds(60)); consumer>shutdown(); return 0; } 使用C++客户端收发顺序消息 简介 顺序消息分为两类，全局顺序消息和分区顺序消息，通过队列数区分。 全局顺序： 对于指定的一个 Topic，所有消息的生产和消费需要遵循一定的顺序，消息的消费顺序必须和生产顺序一致，即需要严格的先入先出 FIFO的顺序进行发布和消费。 分区顺序： 对于指定的一个 Topic，其中每一个分区的消息生产与消费是有序的，同一个队列内的消息按照严格的 FIFO 顺序进行发布和订阅。消息投递到哪一个分区由消息的 Sharding Key 来进行区分。在 SDK 中可以通过指定 Sharding Key 和回调函数来控制消息投递到哪个分区。 发送顺序消息 include include include include "rocketmq/DefaultMQProducer.h" using namespace std; using namespace rocketmq; class DefineSelectMessageQueue : public MessageQueueSelector { public: MQMessageQueue select(const std::vector &mqs, const MQMessage &msg, void arg) { //若希望全局有序，请修改对应index int orderId staticcast (arg); int index orderId % mqs.size(); return mqs[index]; } }; int main(){ DefaultMQProducer producer("groupname"); //填写分布式消息服务RocketMQ版的接入点 producer.setNamesrvAddr("your access point"); //填写分布式消息服务RocketMQ版的ak、sk producer.setSessionCredentials("ak", "sk", "channel"); producer.start(); DefineSelectMessageQueue queueSelector new DefineSelectMessageQueue(); int count 64; for (int i 0; i < count; ++i) { MQMessage msg("youtopicname", "TAG", "msg content"); try { SendResult sendResult producer.send(msg, queueSelector, &i, 3, false); std::cout << "SendResult:" << sendResult.getSendStatus() << ", Message ID: " << sendResult.getMsgId() << std::endl; thisthread::sleepfor(chrono::seconds(1)); } catch (MQException e) { std::cout << "ErrorCode: " << e.GetError() << " Exception:" << e.what() << std::endl; } } std::cout << "Send " << count << " messages OK, costs" << std::endl; producer.shutdown(); return 0; }

创建Queue 可以在代码中声明，会自动创建队列。也可以进入控制台，在实例列表的队列选项卡进行新建。 参数说明如下表所示： 参数 描述 虚拟主机 选择创建队列所属的虚拟主机 名称 队列的名称。以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从3.6.0版本开始引入了惰性队列（Lazy Queue）的概念。惰性队列会尽可能的将消息存入磁盘中，而在消费者消费到相应的消息时才会被加载到内存中，它的一个重要的设计目标是能够支持更长的队列，即支持更多的消息存储。当消费者由于各种各样的原因（比如消费者下线、宕机亦或者是由于维护而关闭等）而致使长时间内不能消费消息造成堆积时，惰性队列就很有必要了 默认情况下，当生产者将消息发送到RabbitMQ的时候，队列中的消息会尽可能的存储在内存之中，这样可以更加快速的将消息发送给消费者。即使是持久化的消息，在被写入磁盘的同时也会在内存中驻留一份备份。当RabbitMQ需要释放内存的时候，会将内存中的消息换页至磁盘中，这个操作会耗费较长的时间，也会阻塞队列的操作，进而无法接收新的消息。虽然RabbitMQ的开发者们一直在升级相关的算法，但是效果始终不太理想，尤其是在消息量特别大的时候 惰性队列会将接收到的消息直接存入文件系统中，而不管是持久化的或者是非持久化的，这样可以减少了内存的消耗，但是会增加I/O的使用，如果消息是持久化的，那么这样的I/O操作不可避免，惰性队列和持久化消息可谓是“最佳拍档”。注意如果惰性队列中存储的是非持久化的消息，内存的使用率会一直很稳定，但是重启之后消息一样会丢失。

配置项 描述 示例 消息队列名称 消息队列自定义标识。 商城北京消息队列 站点 消息队列部署所在站点。 北京站点 产品类型 消息队列技术类型： RocketMQ RocketMQ 实例类型 消息队列产品类型。 云实例 消息队列实例 消息队列对应的云实例ID。 RocketMQ810

功能特性 分布式消息服务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);

本文主要介绍分布式消息服务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节点的性能产生负面影响。 要获得最佳性能，应尽可能缩短队列。建议始终保持队列消息堆积的数量在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条消息。 说明 如果同时使用以上两种方式设置队列的最大长度，两者中较小的值将被使用。 超过队列最大长度的消息会被丢弃，请谨慎使用。

导出死信消息 1. 登录分布式消息服务RocketMQ控制台。 2. 单击RocketMQ实例的名称，进入实例详情页面。 3. 在左侧导航栏，单击“死信队列”，进入“死信队列”页面。 4. 在待导出的死信消息所在行，单击“导出消息”。 导出JSON格式的文件。 说明：如果需要批量导出死信消息，勾选待导出的多条死信消息，单击“批量导出消息”。 导出的消息字段说明如表1所示。 表1 消息字段说明 消息字段 字段说明 msgid 消息ID。 instanceid 实例ID。 topic Topic名称。 storetimestamp 存储消息的时间。 borntimestamp 产生消息的时间。 reconsumetimes 重试次数。 body 消息体。 bodycrc 消息体校验和。 storesize 存储大小。 propertylist 消息属性列表。lname：属性名称。lvalue：属性值。 bornhost 产生消息的主机IP。 storehost 存储消息的主机IP。 queueid 队列ID。 queueoffset 在队列中的偏移量。 重新投递死信消息 死信消息由于某些原因无法正常被消费者消费，请排查相关原因并解决，然后在控制台重新投递死信消息给消费者消费。 1. 登录分布式消息服务RocketMQ控制台。 2. 单击RocketMQ实例的名称，进入实例详情页面。 3. 在左侧导航栏，单击“死信队列”，进入“死信队列”页面。 4. 选择以下任意一种方法重新投递死信消息。 在待重新投递的死信消息所在行，单击“重投”。 如需批量重新投递死信消息，勾选待重新投递的死信消息，单击“批量重投”。 须知： 死信消息重新投递成功后，此死信消息依然存在死信队列中，不会被删除。避免多次重复投递，造成重复消费。

介绍分布式消息服务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的死信和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。