操作场景 分布式消息服务 Kafka 版支持按主题或用户/客户端来配置限流策略，避免因资源消耗过高而影响全量业务。 前提条件 流控管理仅支持集群版实例。 操作步骤 1. 登录管理控制台。 2. 进入Kafka管理控制台。 3. 在实例列表页的操作列，目标实例行点击“管理”按钮。 4. 点击“智能运维”、“流控管理”菜单进入流控管理页面。 5. 如需配置主题流控 ，在流控配置页卡的下拉框选择“Topic”选项并点击“创建流控”按钮。 6. 在弹窗填入主题名、生产上限速率、消费上限速率，点击“确定”按钮。 Topic：填入需要限流的主题名 速率范围：1MB/s — 1024MB/s 7. 如需配置用户/客户端流控 ，在流控配置页卡的下拉框选择“User/Client”选项并点击“创建流控”按钮。 8. 在弹窗填入用户名、客户端ID、生产上限速率、消费上限速率，点击“确定”按钮。 用户名：填入需要限流的用户名，与客户端ID不能同时为空 客户端ID：填入需要限流的客户端ID，与用户名不能同时为空 速率范围：1MB/s — 1024MB/s

本章节主要介绍如何运行Kafka作业。 用户可将自己开发的程序提交到MRS中，执行程序并获取结果。本章节教您在Kafka主题中产生和消费消息。 暂不支持通过界面提交Kafka作业，请通过后台功能来提交作业。 通过后台提交作业 先查询ZooKeeper和Kafka的实例地址，再运行Kafka作业。 查询实例地址（3.x版本） 1.登录MRS管理控制台。 2.选择“集群列表 > 现有集群”，选中一个运行中的集群并单击集群名称，进入集群信息页面。 3.请参考访问FusionInsight Manager（MRS 3.x及之后版本），跳转至FusionInsight Manager页面。然后选择“服务 > ZooKeeper > 实例”，查看ZooKeeper角色实例的IP地址。记录ZooKeeper角色实例中任意一个的IP地址即可。 4.选择“服务 > Kafka > 实例”，查看Kafka角色实例的IP地址。记录Kafka角色实例中任意一个的IP地址即可。 查询实例地址（3.x之前版本） a. 登录MRS管理控制台。 b. 选择“集群列表 > 现有集群”，选中一个运行中的集群并单击集群名称，进入集群信息页面。 c. 在MRS集群详情页面，选择“组件管理 > ZooKeeper > 实例”，查看ZooKeeper角色实例的IP地址。记录ZooKeeper角色实例中任意一个的IP地址即可。 d. 选择“组件管理 > Kafka > 实例”，查看Kafka角色实例的IP地址。记录Kafka角色实例中任意一个的IP地址即可。 运行Kafka作业 MRS 3.x及之后版本客户端默认安装路径为“/opt/Bigdata/client”，MRS 3.x之前版本为“/opt/client”。具体以实际为准。 1.在集群信息页面的“节点管理”页签中单击Master2节点名称，进入弹性云主机管理控制台。 2.单击页面右上角的“远程登录”。 3.根据界面提示，输入Master节点的用户名和密码，用户名、密码分别为root和创建集群时设置的密码。 4.执行如下命令初始化环境变量。 source /opt/Bigdata/client/bigdataenv 5.如果当前集群已开启Kerberos认证，执行以下命令认证当前用户。如果当前集群未开启Kerberos认证，则无需执行该步骤。 kinit MRS集群用户 例如, kinit admin 6.执行如下命令，创建kafka topic。 kafkatopics.sh create zookeeper ZooKeeper角色实例IP:2181/kafkapartitions 2 replicationfactor 2 topic 7.在topic test中产生消息。 首先执行命令kafkaconsoleproducer.sh brokerlist Kafka角色实例IP:9092 topic producer.config /opt/Bigdata/client/Kafka/kafka/config/producer.properties 。 然后输入指定的内容作为生产者产生的消息，输入完成后按回车发送消息。如果需要结束产生消息，使用“Ctrl + C”退出任务。 8.消费topic test中的消息。 kafkaconsoleconsumer.sh topic bootstrapserver Kafka角色实例IP:9092 consumer.config/opt/Bigdata/client/Kafka/kafka/config/consumer.properties 说明 如果集群开启Kerberos认证，则执行如上两个命令时请修改端口号9092为21007，详见

参数 描述 虚拟主机 选择创建队列所属的虚拟主机 名称 队列的名称。以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服务器随机指定一个节点

介绍分布式消息服务Kafka退订操作内容。 场景描述 分布式消息服务kafka为用户提供全面周到的服务，支持用户退订的需求。用户如不需要继续使用该分布式消息服务Kafka实例，可进行删除实例操作，即退订操作。 操作步骤 （1）登录管理控制台。 （2）进入Kafka管理控制台。 （3）在实例列表页在操作列，目标实例行点击“更多”，点击“退订”。 （4）点击“退订”后，会打开新页面，点击“确定” 注意 退订的实例处于冻结状态，请务必在实例退订前停止全部的应用。 在申请退订前，请做好数据备份工作，退订后数据将保留15个自然日，15天后相关数据将不予保留，且不会进行备份，务必谨慎操作。

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

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

本章节介绍Kafka Broker节点主机宕机故障演练。 背景介绍 高性能高可靠的分布式消息服务 Kafka 在复杂分布式环境中仍可能因 Broker 节点宕机引发数据丢失、集群可用性下降、请求延迟升高、副本同步滞后等严重问题，本演练可测试业务系统应对此类核心组件故障的响应能力、高可用切换机制及数据一致性保障效果。 基本原理 指定或随机一个Broker节点进行关机。 故障注入 1、纳管实例资源 1. 导航至 故障演练 > 目标应用 > 应用资源页面。 2. 在资源类型页签中选择分布式消息服务Kafka，然后单击添加资源。 3. 在弹出的对话框中，勾选目标分布式消息服务Kafka实例，单击确定。 2、编排演练任务 1. 导航至 故障演练 > 目标应用 > 演练管理 页面，单击新建演练。 2. 在基本信息 页面，按提示填写演练名称和描述，然后单击下一步。 3. 在演练对象配置页面： 配置动作组 ：为动作组 命名，资源类型选择分布式消息服务Kafka。 添加实例 ：单击添加实例 ，勾选上一步中添加的分布式消息服务Kafka实例。 添加故障动作 ：单击立即添加 ，在列表中选择Broker宕机动作。 4. 在弹出的参数配置框中，配置所需参数，然后单击确定。 持续时间：故障动作持续时间。 故障节点：可选择随机一个节点或者特定的节点。

本章节介绍Kafka Broker节点主机宕机故障演练。 背景介绍 高性能高可靠的分布式消息服务 Kafka 在复杂分布式环境中仍可能因 Broker 节点宕机引发数据丢失、集群可用性下降、请求延迟升高、副本同步滞后等严重问题，本演练可测试业务系统应对此类核心组件故障的响应能力、高可用切换机制及数据一致性保障效果。 基本原理 指定或随机一个Broker节点进行关机。 故障注入 1、纳管实例资源 1. 导航至 故障演练 > 目标应用 > 应用资源页面。 2. 在资源类型页签中选择分布式消息服务Kafka，然后单击添加资源。 3. 在弹出的对话框中，勾选目标分布式消息服务Kafka实例，单击确定。 2、编排演练任务 1. 导航至 故障演练 > 目标应用 > 演练管理 页面，单击新建演练。 2. 在基本信息 页面，按提示填写演练名称和描述，然后单击下一步。 3. 在演练对象配置页面： 配置动作组 ：为动作组 命名，资源类型选择分布式消息服务Kafka。 添加实例 ：单击添加实例 ，勾选上一步中添加的分布式消息服务Kafka实例。 添加故障动作 ：单击立即添加 ，在列表中选择Broker宕机动作。 4. 在弹出的参数配置框中，配置所需参数，然后单击确定。 持续时间：故障动作持续时间。 故障节点：可选择随机一个节点或者特定的节点。

介绍分布式消息服务Kafka续订操作内容。 场景描述 分布式消息服务Kafka为用户提供全面周到的服务，支持用户续订的需求。针对包周期消息实例服务，用户可在到期前进行服务周期延长操作，即续订操作。 操作步骤 （1）登录管理控制台。 （2）进入Kafka管理控制台。 （3）在实例列表页在操作列，目标实例行点击“更多”，点击“续订”。 （4）点击“续订”后，会打开新页面，选择续订时长，会计算出对应价格，点击“确定”，后可到我的订单中支付。

本文主要介绍如何实现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条消息。 说明 如果同时使用以上两种方式设置队列的最大长度，两者中较小的值将被使用。 超过队列最大长度的消息会被丢弃，请谨慎使用。

本章节介绍Kafka Broker节点磁盘IO高负载故障演练。 背景介绍 分布式消息服务 Kafka 集群的性能与稳定性高度依赖底层磁盘 IO 能力，高并发写入、集群数据复制、海量消息存储检索及磁盘故障恢复等场景易导致 Broker 节点磁盘 IO 触达瓶颈，引发消息持久化延迟等问题，本演练可测试业务系统的响应与恢复能力。 基本原理 指定或随机一个Broker节点先通过dd命令将数据写入文件中，然后再通过循环读写文件占用磁盘带宽。 故障注入 1、纳管实例资源 1. 导航至 故障演练 > 目标应用 > 应用资源页面。 2. 在资源类型页签中选择分布式消息服务Kafka，然后单击添加资源。 3. 在弹出的对话框中，勾选目标分布式消息服务Kafka实例，单击确定。 2、编排演练任务 1. 导航至 故障演练 > 目标应用 > 演练管理 页面，单击新建演练。 2. 在基本信息 页面，按提示填写演练名称和描述，然后单击下一步。 3. 在演练对象配置页面： 配置动作组 ：为动作组 命名，资源类型选择分布式消息服务Kafka。 添加实例 ：单击添加实例 ，勾选上一步中添加的分布式消息服务Kafka实例。 添加故障动作 ：单击立即添加 ，在列表中选择Broker 磁盘IO高负载动作。 4. 在弹出的参数配置框中，配置所需参数，然后单击确定。 持续时间：故障动作持续时间。 读负载：开启读压力模式，创建一个临时文件并对其进行持续的读取操作。 写负载：开启写压力模式，持续向一个临时文件写入数据。 块大小：控制单次读写操作的数据块大小，单位为MB。增大此值可以提升单次操作的 IO 压力。通常保持默认值即可。

扩容/缩容代理规格的过程 在扩容/缩容代理规格的过程中，代理采用滚动重启的方式进行实例变更，具体过程如下（以3个代理为例介绍）： 1. 停止Broker 0的Kafka进程 2. 扩容/缩容Broker 0的规格 3. 重启Broker 0的Kafka进程 4. 重复1~3，扩容/缩容Broker 1的规格。 5. 重复1~3，扩容/缩容Broker 2的规格。 图 扩容/缩容代理规格过程 操作步骤 步骤 1 登录管理控制台。 步骤 2 在管理控制台右上角单击，选择区域。 说明 请选择Kafka实例所在的区域。 步骤 3 在管理控制台左上角单击，选择“企业中间件”“分布式消息服务”“Kafka专享版”，进入分布式消息服务Kafka专享版页面。 步骤 4 在实例所在行，单击“更多 > 变更规格”，进入“分布式消息服务Kafka变更规格”页面。 步骤 5 根据实际情况选择扩容存储空间、代理数量、代理规格、基准带宽，或者缩容代理规格。 老规格实例扩容步骤如下： 扩容基准带宽。 在“规格”中，选择扩容后的带宽，单击“下一步”。确认扩容信息无误后，单击“提交”。 在实例列表页面的“规格”中查看扩容后的带宽大小。 说明 扩容带宽是通过扩容代理实现的，原来代理不受影响，业务也不受影响。 新创建的Topic才会分布在新代理上，原有Topic还分布在原有代理上，造成分区分布不均匀。通过 已开启公网访问的实例，在扩容基准带宽时，需要为新扩容的代理设置弹性IP地址。 扩容基准带宽，可以扩大总分区数。 扩容存储空间。 在“存储空间”中，选择扩容后的存储空间大小，单击“下一步”。确认扩容信息无误后，单击“提交”。 在实例列表页面的“可用存储空间”中查看扩容后的存储空间大小。 说明 扩容存储空间不会影响业务。 可用存储空间实际存储空间用于存储日志和ZK的数据的存储空间格式化磁盘的损耗。 例如，实际扩容存储空间到700GB，用于存储日志和ZK的数据的存储空间为100GB，格式化磁盘损耗7GB，那么扩容后的可用存储空间为593GB。 新规格实例扩容步骤如下： 扩容存储空间。 在“变更配置”中，选择“存储空间”，在“单个代理存储空间”中，选择扩容后的单个代理的存储空间大小，单击“下一步”。确认扩容信息无误后，单击“提交”。 在实例列表页面的“可用存储空间”中查看扩容后的总存储空间大小（即扩容后的单个代理的存储空间代理个数）。 说明 扩容存储空间不会影响业务。 可用存储空间实际存储空间用于存储日志和ZK的数据的存储空间格式化磁盘的损耗。 例如，实际扩容存储空间到700GB，用于存储日志和ZK的数据的存储空间为100GB，格式化磁盘损耗7GB，那么扩容后的可用存储空间为593GB。 扩容代理数量。 在“变更配置”中，选择“代理数量”，在“代理数量”中，选择扩容后的代理个数，单击“下一步”。确认扩容信息无误后，单击“提交”。 在实例列表页面的“规格”中查看扩容后的代理个数。 说明 扩容代理数量不会影响原来的代理，业务也不受影响。 新创建的Topic才会分布在新代理上，原有Topic还分布在原有代理上，造成分区分布不均匀。通过 已开启公网访问的实例，在扩容代理数量时，需要为新扩容的代理设置弹性IP地址。 扩容代理数量，可以扩大总分区数。 扩容/缩容代理规格。 在“变更配置”中，选择“代理规格”，在“代理规格”中，选择扩容/缩容后的代理规格，单击“下一步”。确认扩容/缩容信息无误后，单击“提交”。 在实例列表页面的“规格”中查看扩容/缩容后的代理规格。 说明 扩容/缩容代理规格的过程中，节点会重启，可能造成闪断，生产客户端需要配置重试机制。 若Topic为单副本，扩容/缩容期间无法对该Topic生产消息或消费消息。

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

介绍分布式消息服务Kafka的数据保护技术 天翼云分布式消息服务Kafka通过多种数据保护手段和措施，保障您在Kafka实例上的数据的安全性。 容灾 根据数据和服务的不同可靠性需求，您有多种选择。您可以选择在一个可用区（即单个机房）内部署Kafka实例，或者选择跨多个可用区（即同城灾备）进行部署。目前跨可用区在华东1、华南2支持跨可用区部署。具体请参考容灾策略。 副本冗余 通过配置适当数量的副本和分布在不同的节点上，Kafka可以提供高可用性和数据冗余，以保护数据免受节点故障的影响。同时，副本机制还可以提高读取性能，因为客户端可以从就近的副本中读取数据，而不必从远程节点获取数据。 数据持久化 Kafka中数据的持久化是通过将消息写入磁盘上的日志文件来实现的。这种设计使得Kafka能够提供高吞吐量和持久性，即使在发生故障或重启时也能够保留数据。此外，Kafka还提供了数据复制和故障转移机制，以确保数据的可用性和可靠性。

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

Kafka 是按分区一条一条消息顺序向前推进消费的，如果消费端拿到某条消息后执行消费逻辑失败，比如应用服务器出现了脏数据，导致某条消息处理失败，等待人工干预，那么有以下两种处理方式： 失败后一直尝试再次执行消费逻辑。这种方式有可能造成消费线程阻塞在当前消息，无法向前推进，造成消息堆积。 由于 Kafka 自身没有处理失败消息的设计，实践中通常会打印失败的消息、或者存储到某个服务（比如创建一个 Topic 专门用来放失败的消息），然后定时 check 失败消息的情况，分析失败原因，根据情况处理。

本文主要介绍权限管理。 如果您需要对云服务平台上购买的DMS for Kafka资源，给企业中的员工设置不同的访问权限，以达到不同员工之间的权限隔离，您可以使用统一身份认证服务（Identity and Access Management，简称IAM）进行精细的权限管理。该服务提供用户身份认证、权限分配、访问控制等功能，可以帮助您安全的控制云服务资源的访问。 通过IAM，您可以在帐号中给员工创建IAM用户，并使用策略来控制他们对云服务资源的访问范围。例如您的员工中有负责软件开发的人员，您希望他们拥有DMS for Kafka的使用权限，但是不希望他们拥有删除Kafka实例等高危操作的权限，那么您可以使用IAM为开发人员创建用户，通过授予仅能使用Kafka实例，但是不允许删除Kafka实例的权限策略，控制他们对DMS for Kafka资源的使用范围。 如果帐号已经能满足您的要求，不需要创建独立的IAM用户进行权限管理，您可以跳过本章节，不影响您使用DMS for Kafka的其它功能。 IAM是云服务平台提供权限管理的基础服务，无需付费即可使用，您只需要为您帐号中的资源进行付费。 关于IAM的详细介绍，请参见《IAM产品介绍》。 说明 DMS for Kafka的权限与策略基于分布式消息服务DMS，因此在IAM服务中为Kafka分配用户与权限时，请选择并使用“DMS”的权限与策略。 DMS for Kafka权限 默认情况下，管理员创建的IAM用户没有任何权限，需要将其加入用户组，并给用户组授予策略或角色，才能使得用户组中的用户获得对应的权限，这一过程称为授权。授权后，用户就可以基于被授予的权限对云服务进行操作。 DMS for Kafka部署时通过物理区域划分，为项目级服务。授权时，“作用范围”需要选择“区域级项目”，然后在指定区域对应的项目中设置相关权限，并且该权限仅对此项目生效；如果在“所有项目”中设置权限，则该权限在所有区域项目中都生效。访问DMS for Kafka时，需要先切换至授权区域。 权限根据授权精细程度分为角色和策略。 角色：IAM最初提供的一种根据用户的工作职能定义权限的粗粒度授权机制。该机制以服务为粒度，提供有限的服务相关角色用于授权。由于云服务平台各服务之间存在业务依赖关系，因此给用户授予角色时，可能需要一并授予依赖的其他角色，才能正确完成业务。角色并不能满足用户对精细化授权的要求，无法完全达到企业对权限最小化的安全管控要求。 策略：IAM最新提供的一种细粒度授权的能力，可以精确到具体服务的操作、资源以及请求条件等。基于策略的授权是一种更加灵活的授权方式，能够满足企业对权限最小化的安全管控要求。例如：针对DMS for Kafka服务，管理员能够控制IAM用户仅能对实例进行指定的管理操作。多数细粒度策略以API接口为粒度进行权限拆分，DMS for Kafka支持的API授权项请参见《分布式消息服务Kafka API参考》的“权限策略和授权项”章节。 如下表所示，包括了DMS for Kafka的所有系统权限。 表 DMS for Kafka系统权限 系统角色/策略名称 描述 类别 依赖关系 DMS FullAccess 分布式消息服务管理员权限，拥有该权限的用户可以操作所有分布式消息服务的功能。 系统策略 无 DMS UserAccess 分布式消息服务普通用户权限（没有实例创建、修改、删除、扩容）。 系统策略 无 DMS ReadOnlyAccess 分布式消息服务的只读权限，拥有该权限的用户仅能查看分布式消息服务数据。 系统策略 无 DMS VPCAccess 分布式消息服务租户委托时需要授权的VPC操作权限。 系统策略 无 DMS KMSAccess 分布式消息服务租户委托时需要授权的KMS操作权限。 系统策略 无 DMS Administrator 分布式消息服务的管理员权限。 系统角色 依赖Tenant Guest和VPC Administrator。 说明 系统策略有包含OBS授权项，由于缓存的存在，对用户、用户组以及企业项目授予OBS相关的系统策略后，大概需要等待5分钟系统策略才能生效。 下表列出了DMS for Kafka常用操作与系统策略的授权关系，您可以参照该表选择合适的系统策略。 表常用操作与系统策略的关系 操作 DMS FullAccess DMS UserAccess DMS ReadOnlyAccess 创建实例 √ × × 修改实例 √ × × 删除实例 √ × × 变更实例规格 √ × × 重启实例 √ √ × 查询实例信息 √ √ √

本文主要介绍自动续订规则及操作流程。 为避免由于未及时对资源采取续订操作，资源被到期冻结或超期释放，客户购买包月包年产品后，可设置开通自动续订。开通自动续订后，系统将在资源到期前自动续订，无需客户再手动操作。 适用范围 自动续订仅针对采用包月、包年计费模式的资源。 已到期资源不支持设置/修改自动续订。 自动续订仅适于 付费用户 ，不适用于非付费用户。 目前支持设置自动续订的产品有：弹性云主机、GPU云主机、物理机、云桌面、云硬盘、对象存储经典版、云主机备份、专属云计算独享型、专属云存储独享型、弹性IP、共享带宽、天翼云SDWAN、云间高速、关系数据库MySQL版、关系数据库Postgre SQL版、分布式关系数据库、分布式缓存服务Redis版、分布式缓存服务Memcache、文档数据库服务、云HBASE数据库、分布式消息服务RocketMQ、分布式消息服务RabbitMQ、分布式消息服务Kafka、Web应用防火墙、服务器安全卫士、域名无忧、DDos高防IP、云解析、登录保护、网站安全监测、内容安全。 单次最多支持20个资源实例批量续订。 开通、变更、关闭自动续订 用户在续订管理页可开通自动续订功能，变更自动续约周期，或关闭自动续订。 不关闭自动续订的情况下，只要预付费账户余额充足，或为后付费客户，系统将持续按设定的周期自动续订下去。 预付费用户可在官网自主控制自动续订功能的开通、变更、关闭。后付费用户需要客户经理协助开启自动续订权限后才可以自主管理。

本文主要介绍了自动续订规则及操作流程。 为避免由于未及时对资源采取续订操作，资源被到期冻结或超期释放，客户购买包月包年产品后，可设置开通自动续订。开通自动续订后，系统将在资源到期前自动续订，无需客户再手动操作。 适用范围 自动续订仅针对采用包月、包年计费模式的资源。 已到期资源不支持设置/修改自动续订。 自动续订仅适于 付费用户 ，不适用于非付费用户。 目前支持设置自动续订的产品有：弹性云主机、GPU云主机、物理机、云桌面、云硬盘、对象存储经典版、云主机备份、专属云计算独享型、专属云存储独享型、弹性IP、共享带宽、天翼云SDWAN、云间高速、关系数据库MySQL版、关系数据库Postgre SQL版、分布式关系数据库、分布式缓存服务Redis版、分布式缓存服务Memcache、文档数据库服务、云HBASE数据库、分布式消息服务RocketMQ、分布式消息服务RabbitMQ、分布式消息服务Kafka、Web应用防火墙、服务器安全卫士、域名无忧、DDos高防IP、云解析、登录保护、网站安全监测、内容安全。 单次最多支持20个资源实例批量续订。 开通、变更、关闭自动续订 用户在续订管理页可开通自动续订功能，变更自动续约周期，或关闭自动续订。 不关闭自动续订的情况下，只要预付费账户余额充足，或为后付费客户，系统将持续按设定的周期自动续订下去。 预付费用户可在官网自主控制自动续订功能的开通、变更、关闭。后付费用户需要客户经理协助开启自动续订权限后才可以自主管理。

本文介绍Kafka业务数据不均衡最佳实践 方案概述 Kafka将Topic划分为多个分区，所有消息分布式存储在各个分区上。每个分区有一个或多个副本，分布在不同的Broker节点上，每个副本存储一份全量数据，副本之间的消息数据保持同步。Kafka的Topic、分区、副本和代理的关系如下图所示： 在实际业务过程中可能会遇到各节点间或分区之间业务数据不均衡的情况，业务数据不均衡会降低Kafka集群的性能，降低资源使用率。 业务数据不均衡原因： 业务中部分Topic的流量远大于其他Topic，会导致节点间的数据不均衡。 生产者发送消息时指定了分区，未指定的分区没有消息，会导致分区间的数据不均衡。 生产者发送消息时指定了消息Key，按照对应的Key发送消息至对应的分区，会导致分区间的数据不均衡。 系统重新实现了分区分配策略，但策略逻辑有问题，会导致分区间的数据不均衡。 Kafka扩容了Broker节点，新增的节点没有分配分区，会导致节点间的数据不均衡。 业务使用过程中随着集群状态的变化，多少会发生一些Leader副本的切换或迁移，会导致个别Broker节点上的数据更多，从而导致节点间的数据不均衡。 实施步骤 业务数据不均衡的处理措施： 优化业务中Topic的设计，对于数据量特别大的Topic，可对业务数据做进一步的细分，并分配到不同的Topic上。 生产者生产消息时，尽量把消息均衡发送到不同的分区上，确保分区间的数据均衡。 创建Topic时，使分区的Leader副本分散到各个Broker节点中，以保障整体的数据均衡。 Kafka提供了分区重平衡的功能，可以把分区的副本重新分配到不同的Broker节点上，解决节点间负载不均衡的问题。具体分区重平衡的操作请参考修改分区平衡。

本节介绍了分布式消息服务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，消费者，即消息的接受方。 更多信息请参见名词解释。

本节介绍分布式消息服务Kafka实例常见问题 为什么可用区不能选择2个？ Kafka 通常选择三个可用区而不是两个的原因在于数据的容错性和高可用性。通过将副本分布在三个可用区中，Kafka 能够实现更高级别的容错性和可用性，即使一个可用区发生故障，系统仍然可以继续正常运行。这种三个可用区的配置是为了提供更强大的冗余和容错能力，确保 Kafka 集群在面对故障时仍能保持数据的可靠性和可用性。 创建实例时为什么无法查看子网和安全组等信息？ 创建实例时，如果无法查看虚拟私有云、子网、安全组、弹性IP，可能原因是该用户还没创建相关网络实例，需要到对应天翼云网络产品购买相应的网络产品实例。 如何选择实例硬盘大小？ 磁盘大小：流量均值×存储时长×3（备份），建议在迁移上云过程中优化Topic以降低成本。 Kafka实例的超高IO和高IO如何选择？ 选择Kafka磁盘类型主要取决于应用的需求和预算。通常，对于Kafka来说，高IO磁盘是更常见的选择，因为它提供了更好的性能和吞吐量。更多信息请参考计费及购买类问题Kafka磁盘选择超高IO还是高IO？ Kafka服务端支持版本是多少？ 分布式消息服务Kafka支持2.132.8.2版本和2.133.6.2版本服务端。 Kafka实例是否支持修改访问端口？ 分布式消息服务Kafka支持在实例创建时指定访问端口。

介绍分布式消息服务Kafka按位点查询的功能操作内容。 场景描述 Kafka按位点查询是指通过指定偏移量或时间戳来查询Kafka主题中的消息。以下是一些常见的按位点查询的场景描述： 数据回溯：当需要回溯到过去的某个时间点或特定的消息偏移量时，可以使用按位点查询功能。这在故障排查、数据分析和报告生成等场景中非常有用，可以准确地获取特定时间点或消息的数据。 数据恢复：在某些情况下，如果由于意外情况导致数据丢失或损坏，可以使用按位点查询来恢复丢失的数据。通过指定偏移量或时间戳，可以定位到丢失数据之前的位置，然后将数据重新消费或导出。 数据验证：按位点查询还可以用于数据验证和一致性检查。通过指定特定的偏移量或时间戳，可以比较不同主题或分区之间的消息，以确保数据的一致性和正确性。 数据分析：按位点查询对于数据分析和统计也非常有用。通过指定特定的时间戳或偏移量范围，可以获取所需的数据子集，并对其进行进一步的分析和处理。 操作步骤 （1）登录管理控制台。 （2）进入Kafka管理控制台。 （3）在实例列表页在操作列，目标实例行点击“管理”。 （4）点击“消息查询”后默认就是按位点查询。 （5）下拉选择topic可以切换要查询的topic，填写offset消息位置，partition分区编号，可查询该分区offset位置开始的10条消息。 （6）点击消息列表的“消息详情”可查看消息详情信息

如何选择磁盘空间？ Kafka支持多副本存储，副本数量为3。存储空间包含所有副本存储空间总和，因此，您在创建Kafka实例，选择初始存储空间时，建议根据业务消息体积预估以及副本数量选择合适的存储空间。 例如：业务消息体积预估100GB，则磁盘容量最少应为100GB3+ 预留磁盘大小100GB。 如何选择实例带宽？ Kafka实例的网络带宽指单向（读或写）最大带宽。一般建议选择带宽时建议预留30%，确保您的应用运行更稳定。 100MB/s，业务流量为70M以内时推荐选用。 300MB/s，业务流量为210M以内时推荐选用。 Kafka支持磁盘加密吗？ 分布式消息服务Kafka不支持磁盘加密。 Kafka扩容会影响业务吗？ Kafka的扩容过程可能会对业务产生一定的影响，具体取决于您的扩容策略和实施方式。以下是一些可能的影响： 重分区和重新分配：当您需要扩容Kafka集群时，可能需要进行重分区和重新分配。这涉及到数据的重新分布和重新平衡，可能会导致一段时间内的性能下降和延迟增加。在重分区和重新分配期间，Kafka会重新分配副本、重新分区数据，并且可能需要重新加载和重新平衡消费者群组。 网络和磁盘负载增加：扩容Kafka集群意味着增加了更多的节点和副本，这可能会增加网络和磁盘的负载。数据的复制和同步可能会导致网络带宽的消耗，而新增的节点和副本可能会增加磁盘的写入和读取负载。

配置项 说明 名称 日志外送接口的名称。必须为中文字符、字母、数字、“”、“.”或“”，长度不超过 64 字符。 Kafka节点地址 Kafka服务器的IP（域名）及端口号。例如：192.168.0.1:9200。 Kafka主题 消息投放到Kafka服务器的主题。 Kafka分区 消息投放到的Kafka服务器的分区。Kafka服务器通过主题（topic）、分区（partition）和消费组（consumergroup）三个概念灵活适应各种消息场合，通过提升硬件资源利用率提高系统吞吐量。 以上Kafka相关配置与服务器端保持一致即可。 审计日志模板 设置发送审计日志的模板，具体字段请依据填写说明编辑。 操作日志模板 设置发送操作日志的模板，具体字段请依据填写说明编辑。 告警日志模板 设置发送告警日志的模板，具体字段请依据填写说明编辑。 流量控制日志模板 设置发送流量控制日志的模板，具体字段请依据填写说明编辑。

本文介绍分布式消息服务Kafka入门指引的环境准备内容。 概述 在创建天翼云分布式消息服务Kafka实例之前，您需要做一些准备工作。 首先，您需要设置一个虚拟私有云（VPC），这是一个隔离的网络环境，用于托管Kafka实例。 接下来，您需要创建一个子网，它是VPC内部的一个子网络，用于划分不同的部分和区域。 最后，您需要配置一个安全组，用于控制入站和出站的流量规则，以保证Kafka实例的安全性。 每个分布式消息服务Kafka实例都会被部署在特定的VPC中，并与特定的子网和安全组相关联。这种方式可以让您自主配置和管理Kafka实例的网络环境，并提供安全保护策略。如果您已经有了现成的VPC、子网和安全组，可以重复使用它们，无需重复创建。这样可以节省时间和资源，并确保一致性和可靠性。 VPC和子网 VPC和子网可重复使用，您也可以使用不同的VPC和子网来配置Kafka实例，您可根据实际需要进行配置。在创建VPC和子网时应注意如下要求： ● VPC与使用的天翼云分布式消息服务Kafka服务应在相同的区域。 ● 如无特殊需求，创建VPC和子网的配置参数使用默认配置即可。 创建VPC和子网的操作请参考虚拟私有云创建VPC、子网搭建私有网络。 若需要在已有VPC上创建和使用新的子网，请参考虚拟私有云子网管理创建子网。

模块 参数 参数说明 配置示例 备注 配置订阅渠道 网络通道 公网/vpc内网 公网 配置订阅渠道 订阅类型 公网：分布式消息服务/remotewriteAPI/API vpc内网:分布式消息服务 分布式消息服务 配置订阅渠道 类型 对应订阅类型下选择支持的类型 分布式消息服务Kafka 配置订阅渠道 地址 填写分布式消息服务/remotewriteAPI/API目标地址 配置订阅渠道 实例选择 下拉选择所创建的kafka实例（前提：“网络通道”选择“vpc内网”） 配置订阅渠道 用户名 目标地址用户名信息 test 配置订阅渠道 密码 目标地址用户名对应密码信息 配置订阅渠道 TOPIC 目标地址主题（TOPIC） 配置订阅渠道 kafka版本 选择目标客户端kafka版本，2.0.0/2.1.0 2.1.0 2.0.0及以下版本，请选择2.0.0 2.0.0以上版本，请选择2.1.0 基本信息 名称 填写订阅渠道名称 test 基本信息 描述 填写订阅渠道描述信息

模块 参数 参数说明 配置示例 备注 配置订阅渠道 网络通道 公网/vpc内网 公网 配置订阅渠道 订阅类型 公网：分布式消息服务/remotewriteAPI/API vpc内网:分布式消息服务 分布式消息服务 配置订阅渠道 类型 对应订阅类型下选择支持的类型 分布式消息服务Kafka 配置订阅渠道 地址 填写分布式消息服务/remotewriteAPI/API目标地址 配置订阅渠道 实例选择 下拉选择所创建的kafka实例（前提：“网络通道”选择“vpc内网”） 配置订阅渠道 用户名 目标地址用户名信息 test 配置订阅渠道 密码 目标地址用户名对应密码信息 配置订阅渠道 TOPIC 目标地址主题（TOPIC） 配置订阅渠道 kafka版本 选择目标客户端kafka版本，2.0.0/2.1.0 2.1.0 2.0.0及以下版本，请选择2.0.0 2.0.0以上版本，请选择2.1.0 基本信息 名称 填写订阅渠道名称 test 基本信息 描述 填写订阅渠道描述信息

sectionaf1f4cd067bf253e)。 Kafka实例的SSL证书有效期多长？ Kafka实例开启SASL时，需进行单向认证，证书有效期足够长（超过15年），客户端不需要关注证书过期风险。 如何将Kafka实例中的数据同步到另一个Kafka实例中？ Kafka实例之间没有好的实时同步方案，如果需要做实例迁移，可以同时向两个实例生产消息，源实例中的消息可继续消费，待源实例的消息数据全部被消费完或老化后，业务可迁移到新的Kafka实例。 Kafka实例的SASLSSL开关如何修改？ Kafka SASLSSL开关不支持购买实例后修改，在购买时，请慎重选择，如果购买后需要修改，需要重新购买实例。 开启IPv6的实例不支持动态修改SASLSSL开关。 SASL认证机制如何修改？ 实例创建后，不支持修改SASL认证机制。如果需要修改，请重新购买实例。 修改企业项目，是否会导致Kafka重启？ 修改企业项目不会导致Kafka重启。 Kafka服务和ZK是部署在相同的虚拟机中，还是分开部署？ Kafka服务和ZK部署在相同的虚拟机中。 Kafka包周期实例不支持删除吗？ 可以删除。登录Kafka控制台，在包周期实例所在行，单击“更多 > 退订”，完成实例的删除。 Kafka支持哪些加密套件？ 由于安全问题，支持的加密套件为TLSECDHEECDSAWITHAES128CBCSHA256，TLSECDHERSAWITHAES128CBCSHA256和TLSECDHERSAWITHAES128GCMSHA256。 购买实例时选择的单AZ，怎样可以扩展为多AZ？ 已购买的实例无法扩展AZ，请重新购买多AZ的实例。

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

介绍分布式消息服务Kafka重置消费位置功能操作内容。 场景描述 Kafka重置消费位置的场景包括以下几个： 初次消费：当一个新的消费者加入到Kafka集群时，它需要从某个位置开始消费消息。在这种情况下，可以将消费位置重置为最早的消息或最新的消息。 消费者组重置：当消费者组中的消费者发生变化，如新增或退出消费者，可能需要重置消费位置。在这种情况下，可以将消费位置重置为最早的消息或最新的消息。 消费者出现故障：当消费者发生故障，并且需要将其替换或修复时，可能需要重置消费位置。在这种情况下，可以将消费位置重置为最早的消息或最新的消息，以确保新的消费者能够从正确的位置开始消费。 消费者重新处理消息：在某些情况下，消费者可能需要重新处理之前已经消费过的消息。这可能是由于消费者的处理逻辑发生变化，或者需要重新计算之前的结果。在这种情况下，可以将消费位置重置为指定的消息位置，以便消费者重新处理消息。 消费者消费速度过慢：当消费者的处理能力不足，无法及时消费消息时，可能需要重置消费位置。在这种情况下，可以将消费位置重置为最新的消息，以便消费者能够跳过堆积的消息，从最新的消息开始消费。 操作步骤 Tips：目前消费只能重置72小时内的消息，可选择72小时内时间点重置。 （1）登录管理控制台。 （2）进入Kafka管理控制台。 （3）在实例列表页在操作列，目标实例行点击“管理”。 （4）点击“消费组管理”后进入消费组管理页面。 （5）在目标消费组所在行，点击其右侧的“更多”，在下拉框中单击“重置消费位置”。 （6）出现重置消费位置窗口后，可以选择从最新点位开始消费、从最旧点位开始消费、按时间点进行消费位置重置、重置消费点位到附近n条。 四种重置方式试用场景如下： 从最新点位开始消费：将消费者的消费位置重置为最新的消息。这意味着消费者将从当前Kafka主题的最新消息开始消费，忽略之前已经产生的消息。这种方式适用于只关注最新消息的场景，如实时监控或日志记录。 从最旧点位开始消费：将消费者的消费位置重置为最早的消息。这意味着消费者将从当前Kafka主题的最早消息开始消费，包括之前已经产生的消息。这种方式适用于需要处理全部消息历史记录的场景，如数据重播或数据分析。 按时间点进行消费位置重置：将消费者的消费位置重置为指定的时间点。这意味着消费者将从指定时间点之后的消息开始消费，可以精确地选择消费的起始位置。这种方式适用于需要从特定时间点开始消费的场景，如数据回溯或重新处理。 重置消费点位到附近n条：将消费者的消费位置重置到指定的消费位点上，这个是分区级别的，因此可以更加精确地选择消费的起始位置。这种方式适用于需要从特定位点开始消费的场景，如数据回溯或重新处理。

本文主要介绍如何转储日志数据至分布式消息服务Kafka。 云日志服务采集到数据后，支持将数据转储至对天翼云分布式消息服务kafka，用于实时流计算等场景。 前提条件 已创建日志项目和日志单元 已开通天翼云分布式消息服务kafka 已采集到日志 创建日志转储任务 1. 登录云日志服务控制台。 2. 左侧点击【日志转储】菜单，进入日志转储页面。 3. 在页面上方选择“kafka”。 4. 点击【创建转储任务】。 5. 在创建转储任务功能面板，配置如下参数，然后单击确定，完成转储任务创建。 参数 说明 日志项目名称 选择源日志所在的日志项目。 日志单元名称 选择源日志所在的日志单元。 转储任务名称 转储任务的名称。 kafka实例 选择转出目标的kafka实例。 Topic 选择当前kafka的topic。（当前仅支持转储至公有 Topic） 转储时间范围 1、某时间开始：指定转储任务的开始时间，从该时间点开始进行数据转储，直到您手动停止转储任务。(开始时间不得早于当前时间，早于当前时间则以当前时间为准) 2、特定时间范围：指定转储任务的起止时间，转储任务将执行到您指定的结束时间后自动停止。(开始时间不得早于当前时间，早于当前时间则以当前时间为准)