最佳实践
本主题概述使用 Amazon MSK 时应遵循的一些最佳实践。有关 Amazon MSK 复制器最佳实践的信息，请参阅使用 MSK 复制器的最佳实践。
调整集群的大小：每个代理的分区数量
下表显示了建议的每个代理的分区数量（包括领导副本和跟随者副本）。
| 代理大小 | 建议的每个代理的分区数量（包括领导副本和跟随者副本）。 |
|---|---|
kafka.t3.small |
300 |
kafka.m5.large 或 kafka.m5.xlarge |
1000 |
kafka.m5.2xlarge |
2000 |
kafka.m5.4xlarge、kafka.m5.8xlarge、kafka.m5.12xlarge、kafka.m5.16xlarge 或 kafka.m5.24xlarge |
4000 |
kafka.m7g.large 或 kafka.m7g.xlarge |
1000 |
kafka.m7g.2xlarge |
2000 |
kafka.m7g.4xlarge、kafka.m7g.8xlarge、kafka.m7g.12xlarge 或 kafka.m7g.16xlarge |
4000 |
如果每个代理的分区数量超过建议值，并且您的集群过载，则可能会阻止您执行以下操作：
-
更新集群配置
-
将集群更新为较小的代理大小
-
将 Amazon Secrets Manager 密钥与具有 SASL/SCRAM 身份验证的集群关联
大量分区还可能导致 CloudWatch 和 Prometheus 抓取上缺少 Kafka 指标。
有关选择分区数的指导，请参阅 Apache Kafka 支持每个集群 20 万个分区
调整集群的大小：每个集群的代理数量
要确定 MSK 集群的适当代理数量并了解成本，请参阅 MSK Sizing and Pricing
要了解底层基础设施如何影响 Apache Kafka 性能，请参阅 Amazon 大数据博客中的 Best practices for right-sizing your Apache Kafka clusters to optimize performance and cost
优化 m5.4xl、m7g.4xl 或更大实例的集群吞吐量
使用 m5.4xl、m7g.4xl 或更大实例时，您可以通过调整 num.io.threads 和 num.network.threads 配置来优化集群的吞吐量。
Num.io.threads 是代理用于处理请求的线程数。添加更多线程（不超过实例大小支持的 CPU 核心数量）有助于提高集群的吞吐量。
Num.network.threads 是代理用于接收所有传入请求和返回响应的线程数。网络线程将传入请求放在请求队列中，以供 io.threads 处理。将 num.network.threads 设置为实例大小支持的 CPU 核心数量的一半，即可充分使用新的实例大小。
重要
如果不先增加 num.io.threads，请勿增加 num.network.threads，因为这可能会导致与队列饱和相关的拥塞。
| 实例大小 | num.io.threads 的推荐值 | num.network.threads 的推荐值 |
|---|---|---|
m5.4xl |
16 |
8 |
m5.8xl |
32 |
16 |
m5.12xl |
48 |
24 |
m5.16xl |
64 |
32 |
m5.24xl |
96 |
48 |
m7g.4xlarge |
16 |
8 |
m7g.8xlarge |
32 |
16 |
m7g.12xlarge |
48 |
24 |
m7g.16xlarge |
64 |
32 |
使用最新的 Kafka AdminClient 来避免主题 ID 不匹配的问题
当您使用版本低于 2.8.0 且带有标志 --zookeeper 的 Kafka AdminClient 为使用 2.8.0 版或更高版本的 Kafka 的集群增加或重新分配主题分区时，主题 ID 会丢失（错误：与分区的主题 ID 不匹配）。请注意，--zookeeper 标志在 Kafka 2.5 中已弃用，并从 Kafka 3.0 开始删除。请参阅 Upgrading to 2.5.0 from any version 0.8.x through 2.4.x
为防止主题 ID 不匹配，请使用 Kafka 客户端版本 2.8.0 或更高版本进行 Kafka 管理员操作。或者，2.5 及更高版本的客户端可以使用 --bootstrap-servers 标志代替 --zookeeper 标志。
构建高度可用的集群
使用以下建议，以便在更新期间（例如更新代理大小或 Apache Kafka 版本时）或 Amazon MSK 更换代理时，保持 MSK 集群的高可用性。
-
设置三可用区集群。
-
确保复制因子（RF）至少为 3。请注意，在滚动更新期间，RF 为 1 可能会导致分区离线；而 RF 为 2 可能会导致数据丢失。
-
将最小同步副本数 (minISR) 设置为最多 RF - 1。minISR 等于 RF 可能会阻止在滚动更新期间生成到集群。当一个副本处于脱机状态时，minISR 为 2 使三向复制主题可用。
-
确保客户端连接字符串至少包含来自每个可用区的一个代理。在客户端的连接字符串中具有多个代理，则可在特定代理脱机进行更新时实现失效转移。有关如何获取具有多个代理的连接字符串的信息，请参阅获取 Amazon MSK 集群的引导代理。
监控 CPU 使用率
Amazon MSK 强烈建议您将代理的总 CPU 使用率（定义为 CPU User + CPU System）保持在 60% 以下。当集群的总 CPU 可用率至少达到 40% 时，Apache Kafka 可以在必要时在集群中的代理之间重新分配 CPU 负载。例如，当 Amazon MSK 检测到代理故障并从中恢复时，就有必要这样做；在这种情况下，Amazon MSK 会执行自动维护，如进行修补。另一个例子是当用户请求更改代理大小或升级版本时；在这两种情况下，Amazon MSK 会部署滚动工作流程，一次让一个代理离线。当具有领导分区的代理离线时，Apache Kafka 会重新分配分区领导权，以将工作重新分配给集群中的其他代理。通过遵循此最佳实践，您可以确保集群中有足够的 CPU 余量来容忍此类操作事件。
您可以使用 Amazon CloudWatch Metric Math 来创建复合指标，即 CPU User + CPU System。设置当复合指标达到 60% 的平均 CPU 利用率时触发的警报。触发此警报时，请使用以下选项之一扩展集群：
-
选项 1（推荐）：将您的代理大小更新为下一个较大的大小。例如，如果当前大小为
kafka.m5.large，则更新集群以使用kafka.m5.xlarge。请记住，当您更新集群中的代理大小时，Amazon MSK 会以滚动方式使代理离线，并暂时将分区领导权重新分配给其他代理。每个代理的规模更新通常需要 10-15 分钟。 -
选项 2：如果主题中的所有消息都是从使用轮询写入的生成器那里摄取的（换句话说，消息没有密钥，顺序对使用器来说并不重要），请通过添加代理来扩展集群。还要向吞吐量最高的现有主题添加分区。接下来，使用
kafka-topics.sh --describe来确保将新添加的分区分配给新代理。与前一个选项相比，此选项的主要优点是您可以更精细地管理资源和成本。此外，如果 CPU 负载明显超过 60%，则可使用此选项，因为这种形式的扩展通常不会导致现有代理的负载增加。 -
选项 3：通过添加代理来扩展集群，然后使用名为
kafka-reassign-partitions.sh的分区重新分配工具来重新分配现有分区。但是，如果您使用此选项，则在重新分配分区后，集群将需要花费资源将数据从一个代理复制到另一个代理。与前两个选项相比，这可能会在一开始显著增加集群的负载。因此，Amazon MSK 不建议在 CPU 利用率高于 70% 时使用此选项，因为复制会导致额外的 CPU 负载和网络流量。仅当前两个选项不可行时，Amazon MSK 才建议使用此选项。
其他建议：
-
作为负载分配的代理，监控每个代理的 CPU 总利用率。如果代理的 CPU 利用率一直不均衡，则可能表明集群内的负载分布不均。Amazon MSK 建议使用 Cruise Control 通过分区分配持续管理负载分配。
-
监控生成和使用延迟。生成和使用延迟会随着 CPU 利用率呈线性增加。
-
JMX 抓取间隔：如果您使用 Prometheus 功能启用开源监控系统，则建议您为 Prometheus 主机配置 (prometheus.yml) 使用 60 秒或更长的抓取间隔 (scrape_interval: 60s)。降低抓取间隔可能会导致集群上的 CPU 使用率过高。
监控磁盘空间
要避免出现因磁盘空间不足而无法保存消息的情况，可以创建一个用于监控 KafkaDataLogsDiskUsed 指标的 CloudWatch 警报。当此指标的值达到或超过 85% 时，请执行下列一项或多项操作：
-
使用 Amazon MSK 集群的自动扩缩。您也可以手动增加代理存储空间，如 手动扩展 中所述。
-
缩短消息保留期或减小日志大小。有关如何做到这一点的信息，请参阅调整数据保留参数。
-
删除未使用的主题。
有关如何设置和使用警报的信息，请参阅使用 Amazon CloudWatch Alarms。有关 Amazon MSK 指标的完整列表，请参阅监控 Amazon MSK 集群。
调整数据保留参数
使用消息不会将其从日志中删除。要定期释放磁盘空间，您可以明确指定一个保留时间段，即消息在日志中保留的时间。您也可以指定保留日志大小。当达到保留时间段或保留日志大小时，Apache Kafka 会开始从日志中删除非活动段。
要在集群级别指定保留策略，请设置以下一个或多个参数：log.retention.hours、log.retention.minutes、log.retention.ms 或 log.retention.bytes。有关更多信息，请参阅 自定义 Amazon MSK 配置。
您也可以在主题级别指定保留参数：
-
要为每个主题指定一个保留时间段，请使用以下命令。
kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-nameTopicName--add-config retention.ms=DesiredRetentionTimePeriod -
要为每个主题指定一个保留日志大小，请使用以下命令。
kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-nameTopicName--add-config retention.bytes=DesiredRetentionLogSize
您在主题级别指定的保留参数优先于集群级别参数。
在不正常关闭后加快日志恢复
在不正常关闭后，代理可能需要一段时间才能重新启动，因为它需进行日志恢复。默认情况下，Kafka 仅对每个日志目录使用一个线程来执行此恢复。例如，如果您有成千上万个分区，则日志恢复可能需要数个小时才能完成。为加快日志恢复，建议使用配置属性 num.recovery.threads.per.data.dir 增加线程数量。您可以将它设置为 CPU 核心的数量。
监控 Apache Kafka 内存
建议您监控 Apache Kafka 使用的内存。否则，集群可能会变得不可用。
要确定 Apache Kafka 使用了多少内存，您可以监控 HeapMemoryAfterGC 指标。HeapMemoryAfterGC 是垃圾回收后使用的总堆内存百分比。建议您创建一个 CloudWatch 警报，当 HeapMemoryAfterGC 增加到 60% 以上时，该警报将采取行动。
可用于减少内存使用的步骤会有所不同，具体取决于您配置 Apache Kafka 的方式。例如，如果您使用事务性消息传递，则可以将 Apache Kafka 配置中的 transactional.id.expiration.ms 值从 604800000 毫秒减少到 86400000 毫秒（从 7 天减少到 1 天）。这减少了每个事务的内存占用。
请勿添加非 MSK 代理
对于基于 ZooKeeper 的集群，如果您使用 Apache ZooKeeper 命令来添加代理，这些代理将不会添加到 MSK 集群，并且 Apache ZooKeeper 将包含有关集群的错误信息。这可能会导致丢失数据。有关受支持的集群操作，请参阅Amazon MSK 的工作原理。
启用传输中加密
有关传输中加密以及如何启用此加密的信息，请参阅Amazon MSK 传输中加密。
重新分配分区
要将分区移动到同一集群上的不同代理，您可以使用名为 kafka-reassign-partitions.sh 的分区重新分配工具。例如，在添加新代理以扩展集群或移动分区以移除代理之后，您可以通过将分区重新分配给新代理来重新平衡该集群。有关如何向集群添加代理的信息，请参阅扩展 Amazon MSK 集群中的代理数量。有关如何从集群中移除代理的信息，请参阅从 Amazon MSK 集群中移除代理。有关分区重新分配工具的信息，请参阅 Apache Kafka 文档中的扩展集群