资源和成本规划 本实践涉及到的资源和成本规划，如下表所示。 表1 资源和成本规划 资源 资源说明 数量 费用（元） 虚拟私有云VPC 创建一个虚拟私有云VPC。 1 00.00 虚拟私有云子网 创建一个虚拟私有云子网。 1 00.00 安全组 创建一个安全组。 1 00.00 对象存储服务 OBS 创建一个OBS桶。 说明： 创建OBS桶免费，使用阶段请参考OBS计费说明。 1 00.00 分布式消息服务 Kafka版 购买一个Kafka实例，按需计费。 1 例如：kafka.2u4g.cluster 4.35元/小时 事件网格EventGrid 创建一个事件订阅，事件源为OBS应用事件源，事件目标为分布式消息服务Kafka版。 创建一个目标连接，类型为“分布式消息服务 Kafka版”。 1 00.00 本文提供的成本预估费用仅供参考，资源的实际费用以华为云管理控制台显示为准。 父主题： 基于事件订阅将OBS应用事件源消息路由至分布式消息服务Kafka版

升级内核版本的影响 若Topic为单副本，升级期间无法对该Topic生产消息或消费消息，会造成业务中断。 若Topic为多副本，升级不会造成服务中断，但可能会导致消费的分区消息发生乱序，请谨慎评估业务影响，建议您在业务低峰期升级。 升级过程中会逐个节点升级，单个节点的升级包括两部分：升级软件包和数据同步。升级软件包耗时在5分钟左右，数据同步耗时取决于升级软件包过程中其他节点Leader副本的生产数据量，数据量越大，所需时间越久。升级总耗时=每个节点升级软件包耗时+数据同步耗时。 升级过程中会逐个节点重启监控进程，导致监控数据断点，重启成功后，监控数据恢复。 升级过程中节点滚动重启造成分区Leader切换，会发生秒级连接闪断，在用户网络环境稳定的前提下，Leader切换时长一般为1分钟以内。多副本的Topic需要在生产客户端配置重试机制，方法如下： 生产客户端为Kafka开源客户端时，检查是否配置retries参数，建议此参数值设置为3~5。 生产客户端为Flink客户端时，检查是否配置重启策略，配置重启策略可以参考如下代码。 StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();env.setRestartStrategy(RestartStrategies.fixedDelayRestart(3, Time.seconds(20)));

修改定时升级任务 在“后台任务管理”页面的“定时任务”页签中，单击页面左上角下拉框，选择时间段，在搜索对话框中输入“版本升级”，按“Enter”，快速查找定时升级任务。 在待修改的定时升级任务后，单击“修改”。 在弹出的“修改定时任务”对话框中，您可以修改定时升级任务的时间，还可以取消定时升级任务，具体操作如下。 修改定时升级任务的时间：修改时间，单击“确定”。 取消定时升级任务：选择“取消”，单击“确定”。

查看消费者连接地址（Kafka Manager） 登录Kafka Manager。 单击“kafka_cluster”，进入集群详情页。 在顶部导航栏单击“Consumers”，进入消费组列表页面。 图2 导航栏 单击待查看消费者连接地址的消费组名称，进入消费组订阅的Topic列表页面。 图3 消费组列表页面 单击待查看消费者连接地址的Topic名称，进入Topic详情页。 图4 消费组订阅的Topic列表页面 在“Consumer Instance Owner”中，查看消费者连接地址。 图5 Topic详情页

修改定时分区平衡任务 在“后台任务管理”页面的“定时任务”页签中，单击页面左上角下拉框，选择时间段，在搜索对话框中输入待修改定时分区平衡任务的Topic名称，按“Enter”，实现快速查找定时分区平衡任务。 图5 查找定时分区平衡任务 在待修改的定时分区平衡任务后，单击“修改”。 在弹出的“修改定时任务”对话框中，您可以修改定时分区平衡任务的时间，还可以取消定时分区平衡任务，具体操作如下。 修改定时分区平衡任务的时间：修改时间，单击“确定”。 取消定时分区平衡任务：选择“取消”，如图6所示，单击“确定”。 图6 取消定时分区平衡任务

操作影响 对数据量大的Topic进行分区平衡会占用大量的网络和存储带宽，业务可能会出现请求超时或者时延增大，建议在业务低峰期时操作。对Topic进行分区平衡前，根据Kafka实例规格对比当前实例负载情况，评估是否可以进行分区平衡，建议预留足够的带宽进行分区平衡，CPU使用率在90%以上时，不建议进行分区平衡。Topic的数据量和CPU使用率可以通过监控页面的“队列数据容量”和“CPU使用率”查看，具体步骤请参考查看Kafka监控数据。 带宽限制是指设定Topic进行副本同步的带宽上限，确保不会对该实例上的其他Topic造成流量冲击。但需要注意，带宽限制不会区分是正常的生产消息造成的副本同步还是分区平衡造成的副本同步，如果带宽限制设定过小，可能会影响正常的生产消息，且可能会造成分区平衡一直无法结束。如果分区平衡一直无法结束，请联系客服处理。 分区平衡任务启动后，不能删除正在进行分区平衡的Topic，否则会导致分区平衡任务无法结束。 分区平衡后Topic的metadata会改变，如果生产者不支持重试机制，会有少量的请求失败，导致部分消息生产失败。 数据量大的Topic进行分区平衡的时间会比较长。Topic的数据量可以通过监控页面的“队列数据容量”查看，具体步骤请参考查看Kafka监控数据。在不影响业务的前提下，建议适当调小Topic老化时间并等待消息老化，减少迁移数据，加快迁移速度。分区平衡任务结束后可重新调整为初始值。

带宽限制值估算方法 带宽限制值受分区平衡任务执行时间、分区副本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 场景二分区平衡图

测试结果 表2 测试结果 分区数 副本数 是否同步复制 batch.size 是否跨AZ生产 客户端消息生产速率 服务端CPU消耗（broker-0） 服务端CPU消耗（broker-1） 服务端CPU消耗（broker-2） 3 1 否 1KB 否 34128 58.10% 56.70% 53.30% 3 1 否 16KB 否 102399 24.10% 25.00% 23.30% 3 1 否 1KB 是 8523 17.20% 16.70% 18.80% 3 3 是 1KB 否 3981 60.00% 55.20% 50.00% 3 3 否 1KB 否 14468 86.70% 80.60% 86.20% 通过上表的测试结果，得出以下结论，仅供参考： 生产请求的batch.size变大16倍时，客户端消息生产速率增加，服务端CPU消耗减少。 同AZ生产和跨AZ生产相比，客户端消息生产速率增加，服务端CPU消耗也随之增加。 副本从1变成3时，客户端消息生产速率下降较多，服务端CPU消耗增加。 异步复制的Topic和同步复制的Topic相比，客户端消息生产速率增加，服务端CPU消耗也随之增加。

测试环境 进行性能测试前，您需要先构建如下的测试环境： 购买一个Kafka实例，参数信息如下，其他参数保持默认，购买方法请参考购买Kafka实例。 区域：华北-北京四 可用区：可用区1 版本：2.7 部署架构：集群 代理规格：kafka.2u4g.cluster 代理数量：3 单代理存储空间：超高I/O，200GB 虚拟私有云：选择虚拟私有云 子网：选择子网 安全组：选择安全组 访问方式：保持默认 实例名称：kafka-test 企业项目：default 购买完成后，在实例详情页获取Kafka实例的内网明文连接地址。 在购买的Kafka实例中，创建如下参数的3个Topic，具体步骤请参考创建Kafka Topic。 Topic-01：3分区1副本，异步复制 Topic-02：3分区3副本，异步复制 Topic-03：3分区3副本，同步复制 获取测试工具。 获取Kafka命令行工具2.7.2版本。 购买客户端服务器。 购买如下参数的2台E CS 服务器，具体步骤请参考购买弹性云服务器。 区域、可用区、虚拟私有云、子网、安全组与Kafka实例保持一致，规格为4U8G，Linux系统的ECS。 区域、虚拟私有云、子网、安全组与Kafka实例保持一致，“可用区”为“可用区2”，规格为4U8G，Linux系统的ECS。 购买完成ECS后，需要在ECS中完成以下配置： 安装Java JDK，并配置JAVA_HOME与PATH环境变量。 export JAVA_HOME=/root/jdk1.8.0_231 export PATH=$JAVA_HOME/bin:$PATH 下载Kafka命令行工具2.7.2版本，并解压。 tar -zxf kafka_2.12-2.7.2.tgz

测试脚本 ./kafka-producer-perf-test.sh --producer-props bootstrap.servers=${连接地址} acks=1 batch.size=${batch.size} linger.ms=0 --topic ${Topic名称} --num-records ${num-records} --record-size 1024 --throughput 102400 bootstrap.servers：购买Kafka实例中获取的Kafka实例的地址。 acks：消息主从同步策略，acks=1表示异步复制消息，acks=-1表示同步复制消息。 batch.size：每次批量发送消息的大小（单位为字节）。 linger.ms：两次发送时间间隔。 topic：创建Topic中设置的Topic名称。 num-records：总共需要发送的消息数。 record-size：每条消息的大小。 throughput：每秒发送的消息数。

测试步骤 测试场景一：批处理大小 登录客户端服务器，进入“kafka_2.12-2.7.2/bin”目录下，执行以下脚本。 batch.size=1KB，执行脚本如下： ./kafka-producer-perf-test.sh --producer-props bootstrap.servers=192.168.0.69:9092,192.168.0.42:9092,192.168.0.66:9092 acks=1 batch.size=1024 linger.ms=0 --topic Topic-01 --num-records 8000000 --record-size 1024 --throughput 102400 执行结果如下： 8000000 records sent, 34128.673632 records/sec (33.33 MB/sec), 879.91 ms avg latency, 4102.00 ms max latency, 697 ms 50th, 2524 ms 95th, 2888 ms 99th, 4012 ms 99.9th. 客户端消息生产速率=34128 batch.size=16KB，执行脚本如下： ./kafka-producer-perf-test.sh --producer-props bootstrap.servers=192.168.0.69:9092,192.168.0.42:9092,192.168.0.66:9092 acks=1 batch.size=16384 linger.ms=0 --topic Topic-01 --num-records 100000000 --record-size 1024 --throughput 102400 执行结果如下： 100000000 records sent, 102399.318430 records/sec (100.00 MB/sec), 4.72 ms avg latency, 914.00 ms max latency, 1 ms 50th, 5 ms 95th, 162 ms 99th, 398 ms 99.9th. 客户端消息生产速率=102399 登录Kafka实例控制台，单击测试实例名称，进入实例详情页。 在左侧导航栏单击“监控”，进入监控页面。 在“节点”页签，查看服务端节点的CPU使用率。 图1 broker-0的CPU使用率（batch.size=1KB） CPU消耗=58.10% 图2 broker-0的CPU使用率（batch.size=16KB） CPU消耗=24.10% 图3 broker-1的CPU使用率（batch.size=1KB） CPU消耗=56.70% 图4 broker-1的CPU使用率（batch.size=16KB） CPU消耗=25% 图5 broker-2的CPU使用率（batch.size=1KB） CPU消耗=53.30% 图6 broker-2的CPU使用率（batch.size=16KB） CPU消耗=23.30% 测试场景二：是否跨AZ生产 登录客户端服务器，进入“kafka_2.12-2.7.2/bin”目录下，执行以下脚本。 客户端服务器和实例在相同的AZ中，执行脚本如下： ./kafka-producer-perf-test.sh --producer-props bootstrap.servers=192.168.0.69:9092,192.168.0.42:9092,192.168.0.66:9092 acks=1 batch.size=1024 linger.ms=0 --topic Topic-01 --num-records 8000000 --record-size 1024 --throughput 102400 执行结果如下： 8000000 records sent, 34128.673632 records/sec (33.33 MB/sec), 879.91 ms avg latency, 4102.00 ms max latency, 697 ms 50th, 2524 ms 95th, 2888 ms 99th, 4012 ms 99.9th. 客户端消息生产速率=34128 客户端服务器和实例在不同的AZ中，执行脚本如下： ./kafka-producer-perf-test.sh --producer-props bootstrap.servers=192.168.0.69:9092,192.168.0.42:9092,192.168.0.66:9092 acks=1 batch.size=1024 linger.ms=0 --topic Topic-01 --num-records 4000000 --record-size 1024 --throughput 102400 执行结果如下： 4000000 records sent, 8523.042044 records/sec (8.32 MB/sec), 3506.20 ms avg latency, 11883.00 ms max latency, 1817 ms 50th, 10621 ms 95th, 11177 ms 99th, 11860 ms 99.9th. 客户端消息生产速率=8523 登录Kafka实例控制台，单击测试实例名称，进入实例详情页。 在左侧导航栏单击“监控”，进入监控页面。 在“节点”页签，查看服务端节点的CPU使用率。 图7 broker-0的CPU使用率（客户端服务器和实例在相同的AZ中） CPU消耗=58.10% 图8 broker-0的CPU使用率（客户端服务器和实例在不同的AZ中） CPU消耗=17.20% 图9 broker-1的CPU使用率（客户端服务器和实例在相同的AZ中） CPU消耗=56.70% 图10 broker-1的CPU使用率（客户端服务器和实例在不同的AZ中） CPU消耗=16.70% 图11 broker-2的CPU使用率（客户端服务器和实例在相同的AZ中） CPU消耗=53.30% 图12 broker-2的CPU使用率（客户端服务器和实例在不同的AZ中） CPU消耗=18.80% 测试场景三：副本数 登录客户端服务器，进入“kafka_2.12-2.7.2/bin”目录下，执行以下脚本。 1副本，执行脚本如下： ./kafka-producer-perf-test.sh --producer-props bootstrap.servers=192.168.0.69:9092,192.168.0.42:9092,192.168.0.66:9092 acks=1 batch.size=1024 linger.ms=0 --topic Topic-01 --num-records 8000000 --record-size 1024 --throughput 102400 执行结果如下： 8000000 records sent, 34128.673632 records/sec (33.33 MB/sec), 879.91 ms avg latency, 4102.00 ms max latency, 697 ms 50th, 2524 ms 95th, 2888 ms 99th, 4012 ms 99.9th. 客户端消息生产速率=34128 3副本，执行脚本如下： ./kafka-producer-perf-test.sh --producer-props bootstrap.servers=192.168.0.69:9092,192.168.0.42:9092,192.168.0.66:9092 acks=1 batch.size=1024 linger.ms=0 --topic Topic-02 --num-records 4000000 --record-size 1024 --throughput 102400 执行结果如下： 4000000 records sent, 14468.325219 records/sec (14.13 MB/sec), 2069.99 ms avg latency, 7911.00 ms max latency, 846 ms 50th, 6190 ms 95th, 6935 ms 99th, 7879 ms 99.9th. 客户端消息生产速率=14468 登录Kafka实例控制台，单击测试实例名称，进入实例详情页。 在左侧导航栏单击“监控”，进入监控页面。 在“节点”页签，查看服务端节点的CPU使用率。 图13 broker-0的CPU使用率（1副本） CPU消耗=58.10% 图14 broker-0的CPU使用率（3副本） CPU消耗=86.70% 图15 broker-1的CPU使用率（1副本） CPU消耗=56.70% 图16 broker-1的CPU使用率（3副本） CPU消耗=80.60% 图17 broker-2的CPU使用率（1副本） CPU消耗=53.30% 图18 broker-2的CPU使用率（3副本） CPU消耗=86.20% 测试场景四：同步/异步复制 登录客户端服务器，进入“kafka_2.12-2.7.2/bin”目录下，执行以下脚本。 异步复制，执行脚本如下： ./kafka-producer-perf-test.sh --producer-props bootstrap.servers=192.168.0.69:9092,192.168.0.42:9092,192.168.0.66:9092 acks=1 batch.size=1024 linger.ms=0 --topic Topic-02 --num-records 4000000 --record-size 1024 --throughput 102400 执行结果如下： 4000000 records sent, 14468.325219 records/sec (14.13 MB/sec), 2069.99 ms avg latency, 7911.00 ms max latency, 846 ms 50th, 6190 ms 95th, 6935 ms 99th, 7879 ms 99.9th. 客户端消息生产速率=14468 同步复制，执行脚本如下： ./kafka-producer-perf-test.sh --producer-props bootstrap.servers=192.168.0.69:9092,192.168.0.42:9092,192.168.0.66:9092 acks=-1 batch.size=1024 linger.ms=0 --topic Topic-03 --num-records 1000000 --record-size 1024 --throughput 102400 执行结果如下： 1000000 records sent, 3981.937930 records/sec (3.89 MB/sec), 7356.98 ms avg latency, 19013.00 ms max latency, 6423 ms 50th, 14381 ms 95th, 18460 ms 99th, 18975 ms 99.9th. 客户端消息生产速率=3981 登录Kafka实例控制台，单击测试实例名称，进入实例详情页。 在左侧导航栏单击“监控”，进入监控页面。 在“节点”页面，查看服务端节点的CPU使用率。 图19 broker-0的CPU使用率（异步复制） CPU消耗=86.70% 图20 broker-0的CPU使用率（同步复制） CPU消耗=60% 图21 broker-1的CPU使用率（异步复制） CPU消耗=80.60% 图22 broker-1的CPU使用率（同步复制） CPU消耗=55.20% 图23 broker-2的CPU使用率（异步复制） CPU消耗=86.20% 图24 broker-2的CPU使用率（同步复制） CPU消耗=50%

测试环境 进行TPS测试前，您需要先构建如下的测试环境： 购买如表1所示实例，购买步骤请参考购买Kafka实例。 表1 实例参数 名称 代理数量 规格 是否开启SASL 磁盘类型 kafka-01 3 kafka.2u4g.cluster 是 超高I/O kafka-02 3 kafka.4u8g.cluster 是 超高I/O kafka-03 3 kafka.8u16g.cluster 是 超高I/O kafka-04 3 kafka.12u24g.cluster 是 超高I/O kafka-05 3 kafka.16u32g.cluster 是 超高I/O kafka-06 3 kafka.2u4g.cluster 否 超高I/O kafka-07 3 kafka.4u8g.cluster 否 超高I/O kafka-08 3 kafka.8u16g.cluster 否 超高I/O kafka-09 3 kafka.12u24g.cluster 否 超高I/O kafka-10 3 kafka.16u32g.cluster 否 超高I/O kafka-11 3 kafka.2u4g.cluster 否 高I/O kafka-12 3 kafka.4u8g.cluster 否 高I/O kafka-13 3 kafka.8u16g.cluster 否 高I/O kafka-14 3 kafka.12u24g.cluster 否 高I/O kafka-15 3 kafka.16u32g.cluster 否 高I/O 购买完成后，在实例详情页获取Kafka实例的内网明文连接地址。 购买实例后，创建如表2所示Topic，创建步骤请参考创建Kafka Topic。 表2 Topic参数 名称 是否同步复制 是否同步落盘 副本数 分区数 topic-01 否 否 3 30 topic-02 是 否 3 30 topic-03 否 是 3 30 topic-04 否 否 3 3 topic-05 否 否 3 12 topic-06 否 否 3 100 获取测试工具。 获取Kafka命令行工具2.7.2版本。 购买客户端服务器。 购买1台ECS服务器（区域、可用区、虚拟私有云、子网、安全组与Kafka实例保持一致，Linux系统），具体步骤请参考购买弹性云服务器。 购买完成ECS后，需要在ECS中完成以下配置： 安装Java JDK，并配置JAVA_HOME与PATH环境变量。 export JAVA_HOME=/root/jdk1.8.0_231 export PATH=$JAVA_HOME/bin:$PATH 下载Kafka命令行工具2.7.2版本，并解压。 tar -zxf kafka_2.12-2.7.2.tgz

测试脚本 ./kafka-producer-perf-test.sh --producer-props bootstrap.servers=${连接地址} acks=1 batch.size=16384 linger.ms=10 --topic ${Topic名称} --num-records 10000000 --record-size 1024 --throughput -1 --producer.config ../config/producer.properties bootstrap.servers：购买Kafka实例后，获取的Kafka实例的地址。 acks：消息主从同步策略，acks=1表示异步复制消息，acks=-1表示同步复制消息。 batch.size：每次批量发送消息的大小（单位为字节）。 linger.ms：两次发送时间间隔。 topic：创建Topic中设置的Topic名称。 num-records：总共需要发送的消息数。 record-size：每条消息的大小。 throughput：每秒发送的消息数。

测试结果 测试场景一（实例是否开启SASL）：相同的Topic（30分区、3副本、异步复制、异步落盘），实例分为开启SASL和未开启SASL，测试结果如下： 表3 测试结果 实例规格 磁盘类型 代理数量 TPS（开启SASL） TPS（未开启SASL） kafka.2u4g.cluster 超高I/O 3 100000 280000 kafka.4u8g.cluster 超高I/O 3 170000 496000 kafka.8u16g.cluster 超高I/O 3 200000‬ 730000 kafka.12u24g.cluster 超高I/O 3 320000 790000 kafka.16u32g.cluster 超高I/O 3 360000 1000000 结论：在Topic相同的情况下，生产消息到规格相同、接入方式不同的Kafka实例，未开启SASL的实例TPS高于开启SASL的实例TPS。 测试场景二（同步/异步复制）：相同的实例（超高I/O、3个代理、未开启SASL），不同复制机制的Topic，生产者进程数为3时，测试结果如下： 表4 测试结果 实例规格 是否同步落盘 副本数 分区数 TPS（同步复制） TPS（异步复制） kafka.2u4g.cluster 否 3 30 100000 280000 kafka.4u8g.cluster 否 3 30 230000 496000 kafka.8u16g.cluster 否 3 30 342000 730000 kafka.12u24g.cluster 否 3 30 383000 790000 kafka.16u32g.cluster 否 3 30 485000 1000000 结论：生产消息到同一个Kafka实例的不同Topic中，Topic除了复制机制，其他参数相同，异步复制Topic的TPS高于同步复制Topic的TPS。 测试场景三（是否同步落盘）：相同的实例（超高I/O、3个代理、未开启SASL），不同落盘机制的Topic，测试结果如下： 表5 测试结果 实例规格 是否同步复制 副本数 分区数 TPS（同步落盘） TPS（异步落盘） kafka.2u4g.cluster 否 3 30 30000 280000 kafka.4u8g.cluster 否 3 30 32500 496000 kafka.8u16g.cluster 否 3 30 36100 730000 kafka.12u24g.cluster 否 3 30 37400 790000 kafka.16u32g.cluster 否 3 30 40400 1000000 结论：生产消息到同一个Kafka实例的不同Topic中，Topic除了落盘机制，其他参数相同，异步落盘Topic的TPS远远高于同步落盘Topic的TPS。 测试场景四（不同磁盘类型）：相同的Topic（30分区、3副本、异步复制、异步落盘），不同磁盘类型的实例，测试结果如下： 表6 测试结果 实例规格 代理数量 是否开启SASL TPS（高I/O） TPS（超高I/O） kafka.2u4g.cluster 3 否 110000 250000 kafka.4u8g.cluster 3 否 135000 380000 kafka.8u16g.cluster 3 否 213000 480000 kafka.12u24g.cluster 3 否 240000 577000 kafka.16u32g.cluster 3 否 280000 840000 结论：在Topic相同的情况下，生产消息到规格相同、磁盘类型不同的Kafka实例，超高I/O的实例TPS高于高I/O的实例TPS。 测试场景五（不同分区数）：相同的实例（超高I/O、3个代理、未开启SASL），不同分区数的Topic，测试结果如下： 表7 测试结果 实例规格 是否同步落盘 是否同步复制 副本数 TPS（3分区） TPS（12分区） TPS（100分区） kafka.2u4g.cluster 否 否 3 250000 260000 250000 kafka.4u8g.cluster 否 否 3 330000 280000 260000 kafka.8u16g.cluster 否 否 3 480000 410000 340000 kafka.12u24g.cluster 否 否 3 570000 750000 520000 kafka.16u32g.cluster 否 否 3 840000 1000000 630000 结论：生产消息到同一个Kafka实例的不同Topic中，Topic除了分区数量，其他参数相同。随着分区数的增加，Kafka的性能通常会随之增加，当分区数达到一定程度后，继续增加分区数可能会导致性能下降。

前提条件 删除消息前，请先在消费代码中设置“auto.offset.reset”参数。“auto.offset.reset”用来指定当Kafka中没有初始偏移量或者当前偏移量不存在（例如当前偏移量已被删除）时，消费者的消费策略。取值如下： latest：偏移量自动被重置到最晚偏移量。 earliest：偏移量自动被重置到最早偏移量。 none：向消费者抛出异常。 如果将此配置设置为latest，新增分区时，生产者可能会在消费者重置初始偏移量之前开始向新增加的分区发送消息，从而导致部分消息丢失。