云服务器内容精选

  • 带宽限制值估算方法 带宽限制值受分区平衡任务执行时间、分区副本Leader/Follower分布情况以及消息生产速率等因素影响,具体分析如下。 带宽限制值作用范围为整个Broker,对该Broker内所有副本同步的分区进行带宽限流。 带宽限制会将分区平衡后新增的副本视为Follower副本限流,分区平衡前的Leader副本视为Leader副本限流,Leader副本的限流和Follower副本限流分开计算。 带宽限制不会区分是正常的生产消息造成的副本同步还是分区平衡造成的副本同步,因此两者的流量都会被限流统计。 假设分区平衡任务需要在200s内完成,每个副本的数据量为100MB,在以下几种场景中,估算带宽限制值。 场景一:Topic1有2分区2副本,Topic2有1分区1副本,所有Leader副本在同一个Broker上,如表4所示,Topic1和Topic2分别需要新增1个副本,如表5所示。 表4 分区平衡前Topic分区的副本分布 Topic名称 分区名称 Leader副本所在Broker Follower副本所在Broker Topic1 0 0 0,1 Topic1 1 0 0,2 Topic2 0 0 0 表5 分区平衡后Topic分区的副本分布 Topic名称 分区名称 Leader副本所在Broker Follower副本所在Broker Topic1 0 0 0,1,2 Topic1 1 0 0,1,2 Topic2 0 0 0,2 图7 场景一分区平衡图 如图7所示,有3个副本需要从Broker 0拉取数据,Broker 0中每个副本的数据量为100MB,Broker 0中只有Leader副本,Broker 1和Broker 2中只有Follower副本,由此得出以下数据: Broker 0在200s内完成分区平衡所需的带宽限制值=(100+100+100)/200=1.5MB/s Broker 1在200s内完成分区平衡所需的带宽限制值=100/200=0.5MB/s Broker 2在200s内完成分区平衡所需的带宽限制值=(100+100)/200=1MB/s 综上所述,若想要在200s内完成分区平衡任务,带宽限制值应设为大于等于1.5MB/s。由于控制台的带宽限制只能是整数,因此带宽限制值应设为大于等于2MB/s。 场景二:Topic1有2分区1副本,Topic2有2分区1副本,Leader副本分布在不同Broker上,如表6所示,Topic1和Topic2分别需要新增1个副本,如表7所示。 表6 分区平衡前Topic分区的副本分布 Topic名称 分区名称 Leader副本所在Broker Follower副本所在Broker Topic1 0 0 0 Topic1 1 1 1 Topic2 0 1 1 Topic2 1 2 2 表7 分区平衡后Topic分区的副本分布 Topic名称 分区名称 Leader副本所在Broker Follower副本所在Broker Topic1 0 0 0,2 Topic1 1 1 1,2 Topic2 0 1 1,2 Topic2 1 2 2,0 图8 场景二分区平衡图
  • 操作影响 对数据量大的Topic进行分区平衡,会占用大量的网络和存储带宽,业务可能会出现请求超时或者时延增大,建议在业务低峰期时操作。对Topic进行分区平衡前,根据Kafka实例规格对比当前实例负载情况,评估是否可以进行分区平衡,建议预留足够的带宽进行分区平衡,CPU使用率在90%以上时,不建议进行分区平衡。Topic的数据量和CPU使用率可以通过监控页面的“队列数据容量”和“CPU使用率”查看,具体步骤请参考查看Kafka监控数据。 带宽限制是指设定Topic进行副本同步的带宽上限,确保不会对该实例上的其他Topic造成流量冲击。但需要注意,带宽限制不会区分是正常的生产消息造成的副本同步还是分区平衡造成的副本同步,如果带宽限制设定过小,可能会影响正常的生产消息,且可能会造成分区平衡一直无法结束。如果分区平衡一直无法结束,请联系客服处理。 分区平衡任务启动后,不能删除正在进行分区平衡的Topic,否则会导致分区平衡任务无法结束。 分区平衡任务启动后,无法修改Topic的分区数。 分区平衡任务启动后,无法手动停止任务,需要等到任务完成。 已设置了一个定时分区平衡任务,在此任务未执行前,无法对本实例内的任何Topic执行其他分区平衡任务。 分区平衡后Topic的metadata会改变,如果生产者不支持重试机制,会有少量的请求失败,导致部分消息生产失败。 数据量大的Topic进行分区平衡的时间会比较长,建议根据Topic的消费情况,适当调小Topic老化时间,使得Topic的部分历史数据被及时清理,加快迁移速度。Topic的数据量可以通过监控页面的“队列数据容量”查看,具体步骤请参考查看Kafka监控数据。
  • 修改定时分区平衡任务 在“后台任务管理”页面的“定时任务”页签中,单击页面左上角下拉框,选择时间段,在搜索对话框中输入待修改定时分区平衡任务的Topic名称,按“Enter”,实现快速查找定时分区平衡任务。 图5 查找定时分区平衡任务 在待修改的定时分区平衡任务后,单击“修改”。 在弹出的“修改定时任务”对话框中,您可以修改定时分区平衡任务的时间,还可以取消定时分区平衡任务,具体操作如下。 修改定时分区平衡任务的时间:修改时间,单击“确定”。 取消定时分区平衡任务:选择“取消”,如图6所示,单击“确定”。 图6 取消定时分区平衡任务
  • 分区平衡前的准备工作 在不影响业务的前提下,适当调小Topic老化时间并等待消息老化,减少迁移数据,加快迁移速度,分区平衡任务结束后可重新调整为初始值。修改Topic老化时间的步骤,请参考修改Kafka消息老化时间。 确保分区平衡的目标Broker磁盘容量充足,在磁盘存储统计中查看每个Broker的可用磁盘容量。如果目标Broker磁盘剩余容量接近分区平衡迁移到该Broker上的数据量,为了给目标Broker上的消息生产预留存储空间,应先进行磁盘扩容,再进行分区平衡。
  • 带宽限制值估算方法 带宽限制值受分区平衡任务执行时间、分区副本Leader/Follower分布情况以及消息生产速率等因素影响,具体分析如下。 带宽限制值作用范围为整个Broker,对该Broker内所有副本同步的分区进行带宽限流。 带宽限制会将分区平衡后新增的副本视为Follower副本限流,分区平衡前的Leader副本视为Leader副本限流,Leader副本的限流和Follower副本限流分开计算。 带宽限制不会区分是正常的生产消息造成的副本同步还是分区平衡造成的副本同步,因此两者的流量都会被限流统计。 假设分区平衡任务需要在200s内完成,每个副本的数据量为100MB,在以下几种场景中,估算带宽限制值。 场景一:Topic1有2分区2副本,Topic2有1分区1副本,所有Leader副本在同一个Broker上,Topic1和Topic2分别需要新增1个副本 表3 分区平衡前Topic分区的副本分布 Topic名称 分区名称 Leader副本所在Broker Follower副本所在Broker Topic1 0 0 0,1 Topic1 1 0 0,2 Topic2 0 0 0 表4 分区平衡后Topic分区的副本分布 Topic名称 分区名称 Leader副本所在Broker Follower副本所在Broker Topic1 0 0 0,1,2 Topic1 1 0 0,1,2 Topic2 0 0 0,2 图7 场景一分区平衡图 如图7所示,有3个副本需要从Broker 0拉取数据,Broker 0中每个副本的数据量为100MB,Broker 0中只有Leader副本,Broker 1和Broker 2中只有Follower副本,由此得出以下数据: Broker 0在200s内完成分区平衡所需的带宽限制值=(100+100+100)/200=1.5MB/s Broker 1在200s内完成分区平衡所需的带宽限制值=100/200=0.5MB/s Broker 2在200s内完成分区平衡所需的带宽限制值=(100+100)/200=1MB/s 综上所述,若想要在200s内完成分区平衡任务,带宽限制值应设为大于等于1.5MB/s。由于控制台的带宽限制只能是整数,因此带宽限制值应设为大于等于2MB/s。 场景二:Topic1有2分区1副本,Topic2有2分区1副本,Leader副本分布在不同Broker上,Topic1和Topic2分别需要新增1个副本 表5 分区平衡前Topic分区的副本分布 Topic名称 分区名称 Leader副本所在Broker Follower副本所在Broker Topic1 0 0 0 Topic1 1 1 1 Topic2 0 1 1 Topic2 1 2 2 表6 分区平衡后Topic分区的副本分布 Topic名称 分区名称 Leader副本所在Broker Follower副本所在Broker Topic1 0 0 0,2 Topic1 1 1 1,2 Topic2 0 1 1,2 Topic2 1 2 2,0 图8 场景二分区平衡图
  • URI GET /v2/{project_id}/instances/{instance_id}/topics 表1 路径参数 参数 是否必选 参数类型 描述 project_id 是 String 项目ID,获取方式请参见获取项目ID。 instance_id 是 String 实例ID。 表2 Query参数 参数 是否必选 参数类型 描述 limit 否 Integer 查询数量,取值范围为1~50。 offset 否 Integer 偏移量,表示从此偏移量开始查询, offset大于等于0。
  • 响应参数 状态码: 200 表3 响应Body参数 参数 参数类型 描述 total Integer topic总数。 max Integer 最大可创建topic数量。 remaining Integer 剩余可创建topic数量。 next_offset Integer 下个分页的offset。 previous_offset Integer 上个分页的offset。 topics Array of Topic objects topic列表。 表4 Topic 参数 参数类型 描述 name String topic名称。 total_read_queue_num Number 总读队列个数。 total_write_queue_num Number 总写队列个数。 permission String 权限。 brokers Array of brokers objects 关联的代理。 message_type String 消息类型(RocketMQ实例5.x版本才包含此参数)。 缺省值:all 表5 brokers 参数 参数类型 描述 broker_name String 代理名称。 read_queue_num Number 读队列个数。 write_queue_num Number 写队列个数。
  • 响应示例 状态码: 200 查询成功。 { "total" : "3,", "max" : "2000,", "remaining" : "1997,", "next_offset" : "-1,", "previous_offset" : "-1,", "topics" : [ { "name" : "topic-1", "total_read_queue_num" : 3, "total_write_queue_num" : 3, "permission" : "all", "brokers" : [ { "broker_name" : "broker-0", "read_queue_num" : 3, "write_queue_num" : 3 } ], "message_type" : "NORMAL" }, { "name" : "topic-2", "total_read_queue_num" : 3, "total_write_queue_num" : 3, "permission" : "all", "brokers" : [ { "broker_name" : "broker-0", "read_queue_num" : 3, "write_queue_num" : 3 } ], "message_type" : "NORMAL" }, { "name" : "topic-3", "total_read_queue_num" : 3, "total_write_queue_num" : 3, "permission" : "all", "brokers" : [ { "broker_name" : "broker-0", "read_queue_num" : 3, "write_queue_num" : 3 } ], "message_type" : "NORMAL" } ] }
  • 前提条件 导入Topic前,请确保Topic所属的集成应用已创建,否则请提前创建集成应用。 导入Topic前,请检查导入Topic的实例中是否存在重名Topic,若存在重名Topic,会导致导入Topic失败。 导入Topic前,请确保Topic的配额满足需求。 若Topic的描述信息中有换行符时,导出Topic的csv文件中会将换行符转义成“\n”。若使用该csv文件导入Topic,在导入Topic后,需在控制台上手动修改Topic的描述信息,把转义字符“\n”修改成换行符。 导入Topic时,导入的文件中最多包含100个Topic,否则将导入Topic失败。 请勿使用Excel编辑导出的csv文件,否则会打乱csv文件的内容格式,导致导入失败。若需要编辑导出的文件后导入,请导出xlsx或xls格式进行编辑。