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

本章节介绍如何基于消息队列RocketMQ实现全链路灰度 概述 本文介绍在使用消息队列（RocketMQ）这种异步场景下，可以在不修改业务代码的情况下，实现异步场景的灰度，从而实现全链路灰度。本文介绍基于消息队列RocketMQ实现全链路灰度。 背景介绍 在大多数业务场景中对于消息的灰度并没有RPC调用那么严格，但是当全链路灰度调用中涉及到消息消费时，如果消息消费没有按照全链路流量规则路由，则会导致通过消息产生的流量逃逸，从而破坏全链路规则，导致出现一些不符合预期的情况。 如下图所示，本文分别部署网关、appa、appagray、appb、appbgray、appc、appcgray以及RocketMQ，模拟一个真实的全链路灰度场景。 通过网关调用appa应用的接口，当满足路由规则后，灰度流量会被路由到appagray，appagray又会调用appbgray，随后由appbgray发送灰度消息，appcgray将会收到灰度消息，而appc不会收到灰度消息。 前提条件 1. 用户已开通微服务治理中心企业版。 2. 用户已开通云容器引擎。 3. 用户已部署RocketMQ，且RocketMQ版本在4.5.0以上，broker.conf中已配置enablePropertyFiltertrue。 部署Demo应用 准备自建入口网关msgczuul，准备应用msgcappa，msgcappb和msgcappc。调用过程是msgcappa –> msgcappb > msgcappc。 步骤1：在云容器引擎中安装微服务治理插件： 1. 登录“云容器引擎”控制台。 2. 在左侧菜单栏选择“集群”，点击目标集群。 3. 在集群管理页面点击“插件”“插件市场”，选择“cubems”插件安装。 步骤2：为应用开启微服务治理能力： 1. 登录“云容器引擎”控制台。 2. 左侧菜单栏选择“集群”，点击目标集群。 3. 在集群管理页面点击“工作负载”“无状态”，选择目标命名空间。 4. 在Deployment列表页选择指定Deployment，并点击“全量替换”，进入Deployment编辑页。 5. 在Deployment编辑页点击“显示高级设置”，新增“Pod标签”: mseCubeMsAutoEnable:on。 6. 在发布应用时，配置指定环境变量，可指定注入微服务治理中心的应用名、命名空间和标签等信息。 环境变量配置如下： 环境变量名 环境变量值 MSEAPPNAME 接入到微服务治理中心的应用名。 MSESERVICETAG 应用标签信息，如灰度应用可配置gray。 MSENAMESPACE（选填） 接入到微服务治理中心的命名空间，默认为：default。 7. 完成编辑后点击“提交”，重新发布容器即可接入。 appa应用的配置 基线： apiVersion: "apps/v1" kind: "Deployment" metadata: name: "appa" namespace: "default" spec: progressDeadlineSeconds: 600 replicas: 1 revisionHistoryLimit: 10 selector: matchLabels: name: "appa" template: metadata: labels: mseCubeMsAutoEnable: "on" name: "appa" spec: containers: env: name: "MSEAPPNAME" value: "appa" image: "镜像仓库域名/xxx/appa:latest" imagePullPolicy: "Always" name: "appa" ports: containerPort: 26160 livenessProbe: tcpSocket: port: 26160 initialDelaySeconds: 10 periodSeconds: 30 resources: limits: cpu: "1" memory: "1Gi" requests: cpu: "1" memory: "1Gi" 灰度： apiVersion: "apps/v1" kind: "Deployment" metadata: name: "appa" namespace: "default" spec: progressDeadlineSeconds: 600 replicas: 1 revisionHistoryLimit: 10 selector: matchLabels: name: "appa" template: metadata: labels: mseCubeMsAutoEnable: "on" name: "appa" spec: containers: env: name: "MSEAPPNAME" value: "appa" name: "MSESERVICETAG" value: "gray" image: "镜像仓库域名/xxx/appa:latest" imagePullPolicy: "Always" name: "appa" ports: containerPort: 26160 livenessProbe: tcpSocket: port: 26160 initialDelaySeconds: 10 periodSeconds: 30 resources: limits: cpu: "1" memory: "1Gi" requests: cpu: "1" memory: "1Gi" appb应用的配置 基线： apiVersion: "apps/v1" kind: "Deployment" metadata: name: "appb" namespace: "default" spec: progressDeadlineSeconds: 600 replicas: 1 revisionHistoryLimit: 10 selector: matchLabels: name: "appb" template: metadata: labels: mseCubeMsAutoEnable: "on" name: "appb" spec: containers: env: name: "MSEAPPNAME" value: "appb" image: "镜像仓库域名/xxx/appb:latest" imagePullPolicy: "Always" name: "appb" ports: containerPort: 26160 livenessProbe: tcpSocket: port: 26160 initialDelaySeconds: 10 periodSeconds: 30 resources: limits: cpu: "1" memory: "1Gi" requests: cpu: "1" memory: "1Gi" 灰度： apiVersion: "apps/v1" kind: "Deployment" metadata: name: "appb" namespace: "default" spec: progressDeadlineSeconds: 600 replicas: 1 revisionHistoryLimit: 10 selector: matchLabels: name: "appb" template: metadata: labels: mseCubeMsAutoEnable: "on" name: "appb" spec: containers: env: name: "MSEAPPNAME" value: "appb" name: "MSESERVICETAG" value: "gray" image: "镜像仓库域名/xxx/appb:latest" imagePullPolicy: "Always" name: "appb" ports: containerPort: 26160 livenessProbe: tcpSocket: port: 26160 initialDelaySeconds: 10 periodSeconds: 30 resources: limits: cpu: "1" memory: "1Gi" requests: cpu: "1" memory: "1Gi" appc应用的配置 基线： apiVersion: "apps/v1" kind: "Deployment" metadata: name: "appc" namespace: "default" spec: progressDeadlineSeconds: 600 replicas: 1 revisionHistoryLimit: 10 selector: matchLabels: name: "appc" template: metadata: labels: mseCubeMsAutoEnable: "on" name: "appc" spec: containers: env: name: "MSEAPPNAME" value: "appc" image: "镜像仓库域名/xxx/appc:latest" imagePullPolicy: "Always" name: "appc" ports: containerPort: 26160 livenessProbe: tcpSocket: port: 26160 initialDelaySeconds: 10 periodSeconds: 30 resources: limits: cpu: "1" memory: "1Gi" requests: cpu: "1" memory: "1Gi" 灰度： apiVersion: "apps/v1" kind: "Deployment" metadata: name: "appc" namespace: "default" spec: progressDeadlineSeconds: 600 replicas: 1 revisionHistoryLimit: 10 selector: matchLabels: name: "appc" template: metadata: labels: mseCubeMsAutoEnable: "on" name: "appc" spec: containers: env: name: "MSEAPPNAME" value: "appc" name: "MSESERVICETAG" value: "gray" image: "镜像仓库域名/xxx/appc:latest" imagePullPolicy: "Always" name: "appc" ports: containerPort: 26160 livenessProbe: tcpSocket: port: 26160 initialDelaySeconds: 10 periodSeconds: 30 resources: limits: cpu: "1" memory: "1Gi" requests: cpu: "1" memory: "1Gi" zuul应用的配置： apiVersion: "apps/v1" kind: "Deployment" metadata: name: "zuul" namespace: "default" spec: progressDeadlineSeconds: 600 replicas: 1 revisionHistoryLimit: 10 selector: matchLabels: name: "zuul" template: metadata: labels: mseCubeMsAutoEnable: "on" name: "zuul" spec: containers: env: name: "MSEAPPNAME" value: "zuul" image: "镜像仓库域名/xxx/zuul:latest" imagePullPolicy: "Always" name: "zuul" ports: containerPort: 26160 livenessProbe: tcpSocket: port: 26160 initialDelaySeconds: 10 periodSeconds: 30 resources: limits: cpu: "1" memory: "1Gi" requests: cpu: "1" memory: "1Gi"

实施方法 从上面的消费重复场景可以看到，不同Message ID的消息可能有相同的消息内容，因此Message ID无法作为消息的唯一标识符。RocketMQ可以为消息设置Key，把业务的唯一标识作为消息的唯一标识，从而实现消息的幂等。为消息设置Key的示例代码如下： plaintext Message message new Message(); message.setKey("Orderid"); // 设置消息的Key，可以使用业务的唯一标识作为Key，例如订单号等。 SentResult sendResult mqProducer.send(message); 生产者发送消息时，消息已经设置了唯一的Key，在消费者消费消息时，可以根据消息的Key进行幂等处理。消费者通过getKeys()能够读取到消息的唯一标识（如订单号等），业务逻辑围绕该唯一标识进行幂等处理即可。

RocketMQ无法避免消息重复，原因主要有以下几点： 签收的偏移量是定时（每5秒/次）同步到服务端的。 为保证消息不丢失，SDK每次提交的总是队列未签收的最小偏移量（比如无序消费，offset为1、2、3、4、5 的消息，1、3、4、5消费并已签收，2未签收，签收时最后提交的偏移量将会是2，如果此时客户端重启，会从2这个位置开始消费）。 有网络交互就不能确保每一次的交互数据都是送达的，为保证数据不丢失就要进行重试，有重试就存在重复的可能。 如果业务对消费重复非常敏感，务必要注意，建议可以采用以下两种方式处理： 业务层面可以根据msgId做去重处理，如果key字段为业务唯一字段，也可采用key去重。 业务逻辑实现消费幂等，即多次处理同一消息，对业务的影响是幂等的。

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

本文介绍如何在事件总线EventBridge管理控制台添加Apache RocketMQ作为事件流中的服务类型。 前提条件 开通事件总线EventBridge并委托授权。 创建事件流 1. 登录事件总线EventBridge管理控制台，在左侧导航栏，单击事件流。 2. 在创建事件流面板，设置任务名称和描述，配置以下参数，然后单击创建。 1. 在Source（源） 、Filtering（过滤） 、Transform（转换）配置向导，设置数据提供方、事件过滤、转换规则，单击下一步。 2. 在Sink（目标） 配置向导，选择服务类型Apache RocketMQ，配置以下参数。 3. 创建事件流后，会有30秒~60秒的延迟时间，您可以在事件流 页面的状态 栏查看启动进度。 参数说明 参数 说明 示例 接入点 Apache RocketMQ集群broker接入点，由IP与端口号拼接而成，以逗号分隔。 172.17.0.25:9876,192.17.0.26:9876,172.17.0.27:9876 Topic topic名称。 topic1 网络配置 根据业务场景选择对应配置。 专有网络 公网网络 专有网络 VPC 网络配置选择专有网络时必填，选择集群所在的VPC。 vpc 子网 网络配置选择专有网络时必填，选择集群所在的子网。 subnet 认证模式 选择认证模式。 无需配置 ACL 用户名：填写用户名 密码：填写密码 无需配置 消息体 选择消息体（Body）的内容，更多内容请参考事件内容转换。 全部事件 自定义属性 选择自定义属性（Properties）的内容，更多内容请参考事件内容转换。 空 索引 选择索引（Keys）的内容，更多内容请参考事件内容转换。 空 标签 选择标签（Tags）的内容，更多内容请参考事件内容转换。 空

本文介绍如何在事件总线EventBridge管理控制台添加分布式消息服务MQTT类型的自定义事件源。 前提条件 事件总线EventBridge 开通事件总线EventBridge并授权。 创建自定义总线。 分布式消息服务MQTT 开通分布式消息服务MQTT并创建实例。 操作步骤 1. 登录事件总线管理控制台。 2. 在左侧导航栏，单击事件总线。 3. 在事件总线页面，单击目标总线名称。 4. 在左侧导航栏，单击事件源。 5. 在事件源 页面，单击添加事件源。 6. 在添加自定义事件源 面板，输入名称 和描述 ，事件提供方 选择分布式消息服务MQTT，选择或填入主题等配置然后单击确认，如图1所示。 图1 创建事件源时事件提供方选择分布式服务MQTT 参数说明 参数 说明 示例 名称 事件源名。 test MQTT实例 选择MQTT实例。 instancexxx MQTT主题 选择或输入MQTT的主题。 topicxxx 事件示例 plaintext { "id": "b5771f766cdf48edb1bad15418c", "source": "sourcetest", "specversion": "1.0", "subject": "ctyun:mqtt:bb9fdb42056f1xxxxxx2ac110002:dab4124xxxxxx7eb2774f45c6a6db69:topic/

数据库双向同步 应用容灾多活 通过集成数据传输服务 产品能力，支持数据库双向同步功能。您需要到DTS产品控制台开通实例 和创建数据同步任务，并在多活产品控制台进行集成管理。 消息双向同步 应用容灾多活 通过集成分布式消息服务RocketMQ产品能力，支持消息双向同步功能。您可以在多活产品控制台进行集成配置，也可以到分布式消息服务RocketMQ产品控制台进行任务管理。 注册中心同步 应用容灾多活 支持RPC请求的本地优先和异地定向等跨集群调用策略，您需要到微服务引擎 产品控制台配置注册中心双向同步任务。 配额说明 配额是指您在容灾多活产品中可创建的资源数量限制，具体的资源配额如下表所示。 资源 配额 说明 ::: 应用系统 10 单个租户支持的应用系统数量。 站点 2 单个应用系统支持的站点数量。 单元 2 单个站点支持单元数量。 单元组 3 单个应用系统支持的单元组数量。 应用节点 100 单个应用系统支持的应用节点数量。

本文为您介绍分布式消息服务MQTT的产品优势。 分布式消息服务MQTT（Message Queuing Telemetry Transport）是一种轻量级的、发布/订阅模式的消息传递协议，通常用于分布式消息服务和物联网（IoT）应用。以下是MQTT的一些优势： 轻量级协议： MQTT是一种非常轻量级的协议，适用于各种网络环境，包括低带宽、高延迟或不稳定的网络。这使得它非常适合在IoT设备之间传递消息，因为这些设备通常有限的资源和能源。 发布/订阅模式： MQTT采用发布/订阅模式，允许客户端订阅感兴趣的主题，以接收与这些主题相关的消息。这种模式具有灵活性，能够支持多对多的通信，而不需要直接点对点的连接。 异步通信： MQTT允许异步通信，客户端可以发布消息而不必等待接收方的响应。这有助于提高系统的响应速度和吞吐量。 保留消息： MQTT支持保留消息，这意味着最新的消息可以保留在主题中，以便新订阅者可以立即获取到最新数据，而不必等待下一个消息发布。 服务质量（QoS）： MQTT允许设置不同级别的服务质量，从不保证消息送达（QoS 0）到确保消息送达且不重复传递（QoS 2）。这使得可以根据应用的需求选择适当的传递质量。 可伸缩性： MQTT协议可以在大规模分布式系统中轻松扩展，支持成千上万的客户端同时连接到Broker，使其适用于大型IoT解决方案。 消息过滤： MQTT支持使用通配符来订阅主题，这允许客户端根据特定模式匹配多个主题，以接收相关消息。 支持遗愿消息： MQTT支持遗愿消息（Will Messages），允许客户端指定在异常断开连接时发送一条预定义消息。这对于检测设备在线状态非常有用。 跨平台和多语言支持： MQTT具有广泛的跨平台和多语言支持，因此可以在各种设备和编程语言上使用，使得它非常灵活。 安全性： MQTT可以与安全机制（如TLS/SSL）结合使用，确保消息在传输过程中的安全性和隐私。 总的来说，MQTT是一种高效、灵活和可靠的协议，特别适用于分布式消息传递和IoT应用，因此在物联网、远程监控、实时通信等领域得到广泛应用。它的轻量级特性和异步通信使得它成为连接数众多的设备的理想选择。

本节介绍了分布式消息服务RabbitMQ产品常见应用场景。 行业应用 RabbitMQ在需要高效、可靠的消息传递和处理的任何行业都有广泛的应用，常见行业及其实际业务场景如下。 电子商务：RabbitMQ可用于处理订单和库存管理，处理支付通知及其它与物流相关的消息。 金融服务：RabbitMQ可以用于处理实时交易数据、通知和报价，并支持金融机构之间的异步通信。 电信：RabbitMQ可用于处理电话呼叫记录、短信和多媒体消息的分发等。 物流和供应链管理：RabbitMQ可以用于跟踪货物的位置和状态，以及协调供应链中各个环节的消息传递。 社交媒体：RabbitMQ可以用于实现实时消息推送、聊天和通知功能，以及处理用户生成内容。 游戏开发：RabbitMQ可用于处理游戏中的多人互动、玩家间的消息传递和协作。 科学和研究领域：RabbitMQ可以用于分布式计算、任务队列和数据流处理。 RabbitMQ通常用于业务的应用解耦、错峰流控与流量削峰和异步通信场景。 应用解耦 RabbitMQ可以将应用程序之间的耦合度降低，使得系统更加灵活和可扩展。以下是一些使用RabbitMQ实现应用解耦的举例： 订单和库存管理系统：假设有一个在线商店，订单系统负责接收和处理用户的订单，而库存管理系统则负责跟踪库存并更新库存状态。通过使用RabbitMQ，订单系统可以将订单信息发送到一个名为"orderqueue"的消息队列中，而库存管理系统则监听该队列，并在收到订单消息时进行库存更新。这样，订单系统和库存管理系统可以解耦，并且可以独立地进行扩展和维护。 日志处理系统：在一个大规模的分布式系统中，各个服务都会生成大量的日志信息。为了对这些日志进行集中管理和分析，可以使用RabbitMQ作为日志消息的中间代理。每个服务将其产生的日志消息发送到RabbitMQ的一个名为"logqueue"的消息队列中，然后日志处理系统从该队列中消费日志消息，并进行相应的处理和存储。这样，每个服务的日志处理可以独立进行，互不影响。 流量控制系统：在一个微服务架构中，可能会有多个服务实例同时运行，当某个服务实例过载时，传统的负载均衡器无法有效地控制流量分发。通过使用RabbitMQ，可以实现基于消息的流量控制。每个服务实例将其当前的负载情况发送到一个名为"loadqueue"的消息队列中，一个负载控制器订阅该队列，并根据各个服务实例的负载情况来动态调整流量分发。这样，流量控制仍然可以在应用层面进行解耦。

本文为您介绍分布式消息服务MQTT的产品功能。 消息模型 支持发布/订阅消息模型，提供一对多的消息分发方式。这意味着一个发布者（发布消息的客户端）可以将消息发送到一个或多个订阅者（订阅相同主题的客户端），而不需要建立直接的点对点连接。 以下是MQTT的发布/订阅消息模型的关键特点： 主题（Topic）： 发布者在发送消息时会将消息与一个主题相关联。主题是消息的分类或标识，它用于告诉Broker消息应该发送到哪些订阅者。订阅者可以选择订阅感兴趣的主题，以接收与这些主题相关的消息。 订阅（Subscribe）： 订阅者告诉MQTT Broker它对哪些主题感兴趣。一旦订阅者订阅了特定主题，Broker会将匹配的消息发送给订阅者。订阅者可以同时订阅多个主题。 发布（Publish）： 发布者将消息发送到特定主题，然后Broker负责将消息传递给所有订阅了该主题的订阅者。这样，消息可以广播给所有订阅者，实现了一对多的消息分发。 多对多通信： MQTT支持多对多通信，这意味着多个发布者可以同时发布消息到相同或不同的主题，多个订阅者可以同时订阅一个或多个主题。这种灵活性使MQTT适用于各种应用场景，包括物联网、实时通信和分布式系统。 通配符支持： MQTT还支持通配符订阅，订阅者可以使用通配符来匹配多个主题，从而接收与通配符模式匹配的消息。这提供了更高级别的消息过滤和选择性订阅。 总之，MQTT的发布/订阅消息模型使其成为一种非常灵活的消息传递协议，特别适用于需要一对多消息分发的应用，如物联网、实时监控、传感器数据采集等。它的轻量级特性和广泛的跨平台支持也使其成为了许多分布式系统和应用程序的首选通信协议之一。

支持多语言客户端 RabbitMQ是一款基于AMQP协议的开源服务，用于在分布式系统中存储转发消息，服务器端用Erlang语言（支持高并发、分布式以及健壮的容错能力等特点）编写，支持多种语言的客户端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP、AJAX等。

产品优势 分布式消息服务MQTT具有协议丰富、安全可靠、低成本高性能、消息互通等优势，适用于大规模分布式系统中的消息传递和处理场景。 协议丰富： 兼容支持原生多种标准协议，如MQTT、MQTTSN、CoAP、LwM2M；兼容任何支持MQTT协议的 SDK覆盖绝大多数移动端开发平台及开发语言。 安全可靠： 数据安全，支持SSL加密通信，提供身份认证，数据传输更安全可靠。 低成本高性能： 稳定承载大规模终端设备连接，资源占用少；消息路由快速低延时，单集群支持百万规模的路由。 更多信息请参见产品优势。 应用场景 分布式消息服务MQTT可以用于许多应用场景，其灵活性和轻量级特性使其适用于各种需要实时消息传输和发布/订阅模型的应用，如物联网通信、远程监控及控制、传感器数据采集等。 物联网（IoT）通信 MQTT广泛用于连接和管理大规模的物联网设备。它允许传感器、嵌入式设备和其他物联网终端之间进行实时数据通信，以监测环境、收集数据和实现智能控制。 远程监控和控制 MQTT可用于远程监控和控制系统，如监控能源设备、工业自动化、智能家居系统等。它使操作员能够实时监测设备状态，同时可以通过发布命令来实现设备控制。 传感器数据采集 MQTT用于将传感器数据从分布式传感器网络传送到数据中心或云平台，以进行分析和处理。这对于监测环境、天气预报、农业数据收集等非常有用。 更多信息请参见应用场景。

本节介绍产品使用卡券规则。 天翼云分布式消息服务RocketMQ产品卡券使用遵循天翼云统一规则。 ++优惠券使用++ ++代金券使用++ 卡券使用常见问题：卡券管理费用中心常见问题 天翼云。

本章节介绍了如何创建自定义的授权策略。 如果系统预置的DMS for RocketMQ权限，不满足您的授权要求，可以创建自定义策略。自定义策略中可以添加的授权项（Action）请参考细粒度策略支持的授权项。 目前天翼云支持以下两种方式创建自定义策略： 可视化视图创建自定义策略：无需了解策略语法，按可视化视图导航栏选择云服务、操作、资源、条件等策略内容，可自动生成策略。 JSON视图创建自定义策略：可以在选择策略模板后，根据具体需求编辑策略内容；也可以直接在编辑框内编写JSON格式的策略内容。 具体创建步骤请参见：创建自定义策略。本章为您介绍常用的DMS for RocketMQ自定义策略样例。 说明：DMS for RocketMQ的权限与策略基于分布式消息服务DMS，因此在IAM服务中为DMS for RocketMQ分配用户与权限时，请选择并使用“DMS”的权限与策略。 DMS for RocketMQ自定义策略样例 示例1：授权用户删除实例和重启实例 { "Version": "1.1", "Statement": [ { "Effect": "Allow", "Action": [ " dms:instance:delete dms:instance:modifyStatus " ] } ] } 示例2：拒绝用户删除实例 拒绝策略需要同时配合其他策略使用，否则没有实际作用。用户被授予的策略中，一个授权项的作用如果同时存在Allow和Deny，则遵循Deny优先。 如果您给用户授予DMS FullAccess的系统策略，但不希望用户拥有DMS FullAccess中定义的删除实例权限，您可以创建一条拒绝删除实例的自定义策略，然后同时将DMS FullAccess和拒绝策略授予用户，根据Deny优先原则，则用户可以对DMS for RocketMQ执行除了删除实例外的所有操作。拒绝策略示例如下： { "Version": "1.1", "Statement": [ { "Effect": "Deny", "Action": [ "dms:instance:delete" ] } ] }

本节介绍了分布式消息服务RabbitMQ产品常见的名词解释。 Vhost 虚拟主机（Virtual Host），类似于Namespace命名空间的概念，逻辑隔离，每个用户里可以创建多个Vhost，每个Vhost可以创建若干个Exchange和Queue。 Queue 消息队列，每个消息都会被投入到一个或者多个Queue里。 Producer 消息生产者，即投递消息的程序。 Consumer 消息消费者，即接受消息的程序。 Connection TCP 连接，Producer 或 Consumer 与消息队列间的物理 TCP 连接。 Connection将应用与分布式消息服务RabbitMQ连接在一起。Connection会执行认证、IP解析、路由等底层网络任务。应用与分布式消息服务RabbitMQ建立Connection需要多个TCP报文交互，因而会消耗较多的网络资源和分布式消息服务RabbitMQ资源。大量的Connection会对分布式消息服务RabbitMQ造成巨大压力，甚至触发分布式消息服务RabbitMQ SYN洪水攻击防护，导致分布式消息服务RabbitMQ无响应，进而影响业务。 Channel 在客户端的每个物理TCP连接里，可建立多个Channel，每个Channel代表一个会话任务。 Channel是物理TCP连接中的虚拟连接。当应用通过Connection与分布式消息服务RabbitMQ建立连接后，所有的AMQP协议操作（例如创建队列、发送消息、接收消息等）都会通过Connection中的Channel完成。Channel可以复用Connection，即一个Connection下可以建立多个Channel。Channel不能脱离Connection独立存在，而必须存活在Connection中。当某个Connection断开时，该Connection下的所有Channel都会断开。当大量应用需要与分布式消息服务RabbitMQ建立多个连接时，建议您使用Channel来复用Connection，从而减少网络资源和分布式消息服务RabbitMQ资源消耗。 Connection和Channel的使用建议 保持Connection长连接，请勿频繁开启或关闭Connection。如果确实需要频繁开启或关闭连接，请使用Channel。 一个进程对应一个Connection，一个进程中的多个线程则分别对应一个Connection中的多个Channel。 Producer和Consumer分别使用不同的Connection进行消息发送和消费。

场景描述 RocketMQ中的Topic一旦创建后，通常是不允许直接修改的。因为Topic的配置信息会对消息的发送和消费产生影响，直接修改Topic可能导致消息的发送和消费出现问题。 然而，有时候可能会遇到需要修改Topic配置的场景，以下是一些可能的场景描述： 扩展Topic的分区数量：当Topic的消息量增加，原有的分区数量可能无法满足需求时，可以考虑扩展Topic的分区数量。通过修改Topic的配置，增加分区数量，可以提高消息的并发处理能力和负载均衡性能。 修改Topic的生产模式，可能会对消息的发送和消费产生影响，生产模式决定了消息发送的方式和策略，直接修改可能会导致消息发送和消费的异常。 修改Topic的读写权限，需要考虑到消费者和生产者的配置，以确保它们能够正确地读写Topic。 修改Topic备注，用户按照业务需要修改注意备注。 需要注意的是，修改Topic的配置可能会对消息的发送和消费产生影响，因此在进行修改之前，需要谨慎评估和测试，确保不会对现有的消息系统造成不可逆的影响。在实际操作中，建议在创建Topic时就根据业务需求进行充分的规划和配置，避免频繁修改Topic的配置。 操作步骤 1、进入Topic管理菜单，在Topic列表点击【编辑】按钮，进入编辑Topic窗口。 2、Topic修改时，不能修改集群、broker、topic名称；可以修改分区数、读写权限、备注；

本文介绍如何在事件总线EventBridge管理控制台添加分布式消息服务RabbitMQ作为事件流中的事件提供方。 前提条件 事件总线EventBridge 开通事件总线EventBridge并委托授权。 分布式消息服务RabbitMQ 开通分布式消息服务RabbitMQ。 创建所需的vhost和queue。 操作步骤 1. 登录事件总线管理控制台。 2. 在左侧导航栏，单击事件流。 3. 在事件流页面，单击创建事件流。 4. 在事件源（Source）配置 面板，事件提供方 选择分布式消息服务RabbitMQ，选择vhost和queue等配置然后单击确认，如图1所示。 图1 创建事件流时选择分布式消息服务RabbitMQ为事件提供方 参数说明 参数 说明 示例 RabbitMQ实例 选择分布式消息服务RabbitMQ实例。 instancexxx RabbitMQ vhost 选择分布式消息服务RabbitMQ vhost。 / RabbitMQ queue 选择分布式消息服务RabbitMQ queue。 queuexxx 事件示例 plaintext { "id": "b5771f766cdf48edb1bad15418c", "source": "ctyun:rabbitmq", "specversion": "1.0", "subject": "ctyun:rabbitmq:bb9fdb4205xxxxx610242ac110002:16789:queue:topicqueue", "time": "20240305T13:52:18.374Z", "datacontenttype": "application/json;charsetutf8", "type": "ctyun.rabbitmq.topic.sendMessage", "ctyunregion": "bb9fdb4205xxxxx610242ac110002", "ctyunaccountid": "123456789", "data": { "envelope": { "messageId": "xx", "contentEncoding": "UTF8", "contentType": "application/json" }, "body": { "key": "value" }, "props": { "deliveryTag": 98, "exchange": "", "redeliver": false, "routingKey": "housekeeping" } } } data字段包含的参数解释如下表所示： 参数 类型 示例值 描述 props Object 详见props字段参数解释 消息属性，详见props字段参数解释。 envelope Object 详见envelope字段参数解释 消息的envelope信息，详见envelope字段参数解释。 body Object {"key":"value"} 消息体，默认以JSON格式编码。 data 字段下envelope属性包含的参数解释如下表所示： 参数 类型 示例值 描述 deliveryTag Integer 98 消息的Tag。 exchange String / 消息的Exchange。 redeliver Boolean false 是否支持重发消息。取值说明如下： true：支持。 false：不支持。 routingKey String housekeeping 消息的路由规则。 data 字段下props属性包含的参数解释如下表所示： 参数 类型 示例值 描述 contentEncoding String utf8 消息内容编码。 messageId String f7622d51e19841dea07277c1ead7 消息ID。 contentType String application/json 消息contentType。

本章节介绍消息灰度功能的使用 概述 在使用全链路灰度能力时，若涉及消息的灰度，可以开启消息灰度能力。 版本限制 框架 限制 详情 RocketMQ 4.5.0+ 当前只支持RocketMQ的灰度。 jdk版本 1.8+ 无。 开启消息灰度 1.登录微服务治理中心控制台。 2.在左侧导航栏选择 微服务治理中心 >应用治理。 3.在应用治理页面单击目标应用卡片。 4.在左侧导航栏选择流量治理 消息灰度，即可配置消息灰度规则。 消息灰度参数说明： 参数 说明 未打标环境忽略标签 未打标环境默认会消费所有环境的消息。若配置“未打标环境忽略标签”，则未打标环境会忽略配置的标签。 开启消息灰度开关 消息灰度生效开关。 消息灰度过滤侧 客户端过滤：在消费端MSE Agent过滤，会拉取所有的消息，建议提前评估消息量。 服务端过滤：在服务端通过SQL92方式过滤，需要RocketMQ服务端支持。

应用进程、消费组、消费者实例的关系 消费组可以有多个消费者实例。 同一进程，同一个消费组不允许有相同的消费者实例。 不同进程，不能创建相同消费者实例，如上图中的实例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 必须一致。

如何开启ipv6访问？ 在开通实例时，您需要选择已开启ipv6的VPC与子网，并打开ipv6开关。开通完成后，将自动为实例分配ipv6地址。您可登录实例控制台获取ipv6连接地址，可通过IPv6地址段访问实例。 应用客户端 连接拒绝Connect faild 解决方案：当出现这类问题时，检查当前网络并无异常时，并排查下ulimit –a openfiles是否为1024，修改至65535。 超时异常RemotingTimeoutException 服务器端日志出现RemotingTimeoutException：wait response on the channel timeout, 3000ms。 解决方案：这类情况一般由于客户端与服务端通信出现问题，可以ping Ip 以及telnet ip port 来排查这类，同时也要检查防火墙的问题。 找不到路由No route info of this topic 问题可能原因： 没创建topic。 name server填错了。 网络问题无法获取路由。 解决方案： 在管理台创建topic。 检查客户端配置的namesrv的地址是否配错了。 检查网络是否正常。 备不可用SLAVENOTAVAILABLE 当生产者发送消息时，出现“status:SLAVENOTAVAILABLE”，说明从节点发生状况。 解决方案： 从节点机器出现问题，重启从节点，并查看网络连接。 在多网卡情况下，broker配置文件properties中，需增加配置项，例如：brokerIP110.4.246.130，brokerIP210.4.246.130 防止网卡ip读取错误，取不到从节点信息。 消息体大小越界 客户端报此类异常Fail to send message, for: message body size over max message size, max: 524288。 解决方案： 检查服务端的最大消息体大小，即启动broker配置文件的maxMessageSize大小，如未配置，默认是512K。 检查客户端设置的最大消息体(默认128k)是否小于当前发送的消息体大小。 注意：ROCKETMQ建议消息体在50K或以下(压缩后)。

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

参数 说明 示例 名称 事件源名。 source1 接入点 Apache RocketMQ集群broker接入点，由IP与端口号拼接而成，以逗号分隔。 172.17.0.25:9876,192.17.0.26:9876,172.17.0.27:9876 Topic topic名称。 topic1 Group ID 填入当前Apache Kafka集群中已创建的Group，请不要与已有业务的Group混用，以免影响已有的消息收发。 group1 Tag 用于消息过滤的Tag，非必填。 tag 网络配置 根据业务场景选择对应配置。 专有网络 公网网络 专有网络 VPC 网络配置选择专有网络时必填，选择集群所在的VPC。 vpc 子网 网络配置选择专有网络时必填，选择集群所在的子网。 subnet 认证模式 选择认证模式。 无需配置 ACL 用户名 ：填写用户名 密码 ：填写密码 无需配置 消费位点 消费消息的位点。 最早位点 最早位点 数据格式 消息value数据编码格式。 JSON Text Binary JSON

本文介绍如何应用事件总线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秒的延迟时间，您可以在事件流页面的状态栏查看启动进度。

介绍分布式消息服务RabbitMQ与天翼云其他服务关系。 虚拟私有云(CTVPC，Virtual Private Cloud) 虚拟私有云为分布式消息服务RabbitMQ提供一个逻辑隔离的区域，构建一个安全可靠、 可配置和管理的虚拟网络环境。更多信息请参见虚拟私有云。 弹性云主机（CTECS，Elastic Cloud Server） 分布式消息服务RabbitMQ订购后，默认按照用户选择的实例规格开通弹性云主机，云主机由 CPU、内存、镜像、云硬盘组成，同时结合VPC、安全组、数据多副本保存等能力，打造一个既高效又可靠安全的计算环境，确保分布式消息服务RabbitMQ持久稳定运行。更多信息请参见弹性云主机。 云硬盘（CTEVS，Elastic Volume Service） 分布式消息服务RabbitMQ订购后，默认按照用户选择的存储大小开通云硬盘。云硬盘是一种可弹性扩展的块存储设备，可以为分布式消息服务RabbitMQ提供高性能、高可靠的块存储服务。更多信息请参见云硬盘。 弹性IP（Elastic IP，EIP） 弹性IP是可以独立申请的公网 IP 地址，包括公网IP地址与公网出口带宽服务。可以与分布式消息服务RabbitMQ动态绑定和解绑，实现云资源的互联网访问。针对需要公网访问分布式消息服务RabbitMQ实例的需求，用户可开通弹性IP后，在RabbitMQ实例开通页面进行绑定。更多信息请参见弹性IP。

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

本节介绍了分布式消息服务RabbitMQ产品相关协议。 产品服务等级协议请查看： 分布式消息服务RabbitMQ服务等级协议

参数 说明 示例 RabbitMQ 实例名称 分布式消息服务RabbitMQ实例名称。 instancexxx RabbitMQ vhost 分布式消息服务RabbitMQ vhost。 / RabbitMQ queue 分布式消息服务RabbitMQ queue。 queuexxx

结果验证 1. 使用事件源触发一个事件事件。 2. 您可以在分布式消息RabbitMQ 控制台确认是否接收到事件。 1. 登录分布式消息服务RabbitMQ控制台，然后在左侧导航栏选择实例列表。 2. 在实例列表页面单击目标实例名称。 3. 在选择队列管理，进入目标队列详情，进入消息消费拨测页面。 4. 在消息查询页面，点击消费即可查看消息内容， 如图2所示。 图2 在分布式消息服务RabbitMQ管理控制台中查看消息详情

系统角色/策略名称 描述 类别 依赖关系 DMS FullAccess 分布式消息服务管理员权限，拥有该权限的用户可以操作所有分布式消息服务的功能。 系统策略 无 DMS UserAccess 分布式消息服务普通用户权限（没有实例创建、修改、删除、扩容）。 系统策略 无 DMS ReadOnlyAccess 分布式消息服务的只读权限，拥有该权限的用户仅能查看分布式消息服务数据。 系统策略 无 DMS VPCAccess 分布式消息服务租户委托时需要授权的VPC操作权限。 系统策略 无 DMS KMSAccess 分布式消息服务租户委托时需要授权的KMS操作权限。 系统策略 无 DMS Administrator 分布式消息服务的管理员权限。 系统角色 依赖Tenant Guest和VPC Administrator。

本文主要介绍天翼云分布式消息服务RabbitMQ的产品定义。 天翼云分布式消息服务RabbitMQ完全兼容开源RabbitMQ，为您提供即开即用、消息特性丰富、灵活路由、高可用、监控和告警等特性，广泛应用于秒杀、流控、系统解耦等场景。 即开即用 天翼云分布式消息服务RabbitMQ提供单机和集群的消息实例，拥有丰富内存规格，您可以通过控制台直接下单购买并创建，无需单独准备服务器资源。 消息特性丰富 支持AMQP协议，支持普通消息、广播消息、死信、延迟消息等特性。 灵活路由 在RabbitMQ中，生产者将消息发送到交换器，由交换器将消息路由到队列中。交换器支持Direct、Topic、Headers和Fanout四种路由方式，同时支持交换机组合和自定义。 高可用 RabbitMQ集群提供镜像队列，可通过镜像在其他节点同步数据，单节点宕机时，仍可通过唯一的访问地址对外提供服务，数据不丢失。 监控和告警 支持对RabbitMQ实例状态进行监控，支持对集群每个代理的内存、CPU、网络流量等进行监控。如果集群或节点状态异常，将触发告警。

系统角色/策略名称 描述 类别 依赖关系 DMS FullAccess 分布式消息服务管理员权限，拥有该权限的用户可以操作所有分布式消息服务的功能。 系统策略 无 DMS UserAccess 分布式消息服务普通用户权限（没有实例创建、修改、删除、扩容）。 系统策略 无 DMS ReadOnlyAccess 分布式消息服务的只读权限，拥有该权限的用户仅能查看分布式消息服务数据。 系统策略 无 DMS Administrator 分布式消息服务的管理员权限。 系统角色 依赖Tenant Guest和VPC Administrator。