使用ACL权限访问 实例开启ACL访问控制后，消息生产者和消费者都需要增加用户认证信息。 准备环境 开源的Java客户端支持连接分布式消息服务RocketMQ版，推荐使用的客户端版本为4.9.8。 通过以下任意一种方式引入依赖： 使用Maven方式引入依赖。 <dependency>

查看更多 →

普通消息：没有特殊功能的消息，区别于延迟消息、顺序消息和事务消息。 延迟消息/定时消息：生产者生产消息到分布式消息服务RocketMQ版后，消息不会立即被消费，而是延迟到特定时间后才会发送给消费者进行消费。 顺序消息：消费者按照消息发送的顺序来消费消息。 事务消息：提供类似X/Open XA的分

查看更多 →

高可靠、高吞吐、动态扩展、便捷多样的消息中间件服务。用户购买RocketMQ实例后，生产者客户端连接RocketMQ实例进行消息生产，生产的消息被存储在RocketMQ实例的Topic中，消费者客户端通过订阅Topic消费消息。 使用RocketMQ实例生产消费消息的流程如下图所示。

查看更多 →

事务消息交互流程 事务消息生产者首先发送半消息，然后执行本地事务。如果执行成功，则发送事务提交，否则发送事务回滚。服务端在一段时间后如果一直收不到提交或回滚，则发起回查，生产者在收到回查后重新发送事务提交或回滚。消息只有在提交之后才投递给消费者，消费者对回滚的消息不可见。 收发事

查看更多 →

监控”，进入管道监控页面。 图3 进入数据监控页面 在数据管道的监控页面，查看监控指标。 图4 数据监控 总览：显示当前管道中生产者、管道、订阅器、消费者之间生产速率等信息。 生产者：显示生产者的“当前生产TPS”、“当前生产速率”、“当前生产数量”、“当前消息存储大小”等相关指标信息。 管道：显示

查看更多 →

实际使用中，生产者端要做好消息的分类，便于消费者可以使用Tag进行消息的准确订阅。而在消费者端，则要保证订阅关系的一致性。 错误的订阅关系 同一消费组下的消费者订阅了不同的Topic 例如，消费组Group1下有消费者A和消费者B，消费者A订阅了Topic A，消费者B订阅了Topic

查看更多 →

消费端处理，这样队列中就会产生大量的消息堆积。 消费者出现异常，生产者一直在发送消息，但是消费者不能消费，造成消息积压。 消费者没有出现异常，但是消费者与队列间的订阅可能出现了异常，也会导致消息无法被消费从而造成堆积的情况。 消费者正常，与队列间的订阅也正常，但是消费端的代码本身

查看更多 →

频繁打开和关闭连接或通道会发送和接收大量的TCP包，从而导致更高的延迟，确保不要频繁打开和关闭连接或通道。 生产者和消费者使用不同的连接 生产者和消费者使用不同的连接以实现高吞吐量。当生产者发送太多消息给服务端处理时，RabbitMQ会将压力传递到TCP连接上。如果在同一个TCP连接上消费

查看更多 →

} 客户端使用建议 生产者端 网络异常可能导致消息路由失效，消息丢失。建议在生产者客户端中将Mandatory参数设置为“true”，以便在Exchange根据路由规则无法将消息路由到符合条件的Queue时，调用Basic.Return方法将消息返回给生产者。 以下示例演示在Java客户端开启Mandatory：

查看更多 →

事务消息交互流程 事务消息生产者首先发送半消息，然后执行本地事务。如果执行成功，则发送事务提交，否则发送事务回滚。服务端在一段时间后如果一直收不到提交或回滚，则发起回查，生产者在收到回查后重新发送事务提交或回滚。消息只有在提交之后才投递给消费者，消费者对回滚的消息不可见。 收发事

查看更多 →

Kafka应用开发建议 同一个组的消费者的数量建议与待消费的Topic下的Partition数保持一致 若同一个组的消费者数量多于Topic的Partition数时，会有多余的消费者一直无法消费该Topic的消息，若消费者数量少于Topic的Partition数时，并发消费得不到完全体现，因此建议两者相等。

查看更多 →

Sheet中生产者和消费者环境不一致。 请检查导入文件MQ Sheet中生产者和消费者环境是否一致。 MQ Sheet中生产者和消费者服务或微服务在Application Sheet中不存在。 请在导入文件的Application Sheet补齐MQ Sheet中生产者和消费者服务或微服务。

查看更多 →

XDEL key ID [ID ...] XGROUP 该命令用于管理流数据结构关联的消费者组。使用XGROUP你可以： 创建与流关联的新消费者组。 销毁一个消费者组。 从消费者组中移除指定的消费者。 将消费者组的最后交付ID设置为其他内容。 XGROUP [CREATE key groupname

查看更多 →

latest：自动复位offset为最新 none：如果没有发现offset，则向消费者抛出异常 anything else：向消费者抛出异常。 说明： 如果将此配置设置为latest，新增分区时，生产者可能会在消费者重置初始偏移量之前开始向新增加的分区发送消息，从而导致部分消息丢失。 connections

查看更多 →

延迟。 生产者和消费者使用独立的连接，来提高吞吐量。 大量的连接和通道可能会影响管理接口的性能，造成请求超时。 消息确认 消费者使用确认（Acknowledgment）机制避免消息因为连接问题而丢失，客户端可以在收到消息或者处理完消息后回给服务端一个 ack 消息。消费者确认机制

查看更多 →

列表页面。 单击待查看消费者列表的消费组名称，进入消费组详情页。 在“消费者列表”页签，查看消费者列表。 在消费者列表中，可以查看消费者ID、消费者地址和客户端ID。 （可选）如果需要查询某个消费者，在搜索框中，输入消费者ID，按“Enter”。 查看消费者列表（客户端） 未开启

查看更多 →

事务消息交互流程 事务消息生产者首先发送半消息，然后执行本地事务。如果执行成功，则发送事务提交，否则发送事务回滚。服务端在一段时间后如果一直收不到提交或回滚，则发起回查，生产者在收到回查后重新发送事务提交或回滚。消息只有在提交之后才投递给消费者，消费者对回滚的消息不可见。 收发事

查看更多 →

RabbitMQ实例采用物理隔离的方式部署，租户独占RabbitMQ实例。 创建Vhost 生产者和消费者连接RabbitMQ实例时，需要指定一个Vhost。 创建Exchange 生产者向RabbitMQ实例发送消息时，不会直接将消息发送到Queue，而是先将消息发送到Exch

查看更多 →

分布式消息服务RocketMQ版支持任意时间的定时消息，最大推迟时间可达到1年。 定时消息即生产者生产消息到分布式消息服务RocketMQ版后，消息不会立即被消费，而是延迟到设定的时间点后才会发送给消费者进行消费。 发送定时消息前，请参考收集连接信息收集RocketMQ所需的连接信息。

查看更多 →

nkedIn开发。它是一个高吞吐量、低延迟的平台，可以处理大量的实时数据流。Kafka主要由三个部分组成：生产者、消费者和代理 服务器 。生产者将数据发布到Kafka集群，消费者从Kafka集群订阅数据并进行处理，代理服务器则是Kafka集群中的核心组件，负责处理消息的存储和转发。K

查看更多 →

使用ACL权限访问 实例开启ACL访问控制后，消息生产者和消费者都需要增加用户认证信息。 生产者增加用户认证信息 普通消息、顺序消息和定时消息，参考如下代码。以下加粗内容需要替换为实例自有信息，请根据实际情况替换。 from rocketmq.client import Producer

查看更多 →