本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 快速代理的最佳实践
<a name="bestpractices-express"></a>

本主题概述了使用快速代理时应遵循的一些最佳实践。快速代理已预先配置为实现高可用性和持久性。默认情况下，数据分布在三个可用区中，复制始终设置为 3，最小同步副本始终设置为 2。但是，要优化集群的可靠性和性能，仍需考虑几个因素。

## 客户端注意事项
<a name="bestpractices-client-considerations"></a>

应用程序的可用性和性能不仅取决于服务器端设置，还取决于客户端的设置。
+ 为您的客户端配置高可用性 在 Apache Kafka 这样的分布式系统中，确保高可用性对于维护可靠且容错的消息传递基础设施至关重要。代理将因计划内和计划外事件（例如升级、修补、硬件故障和网络问题）而离线。Kafka 集群可以容忍代理离线，因此 Kafka 客户端也必须妥善处理代理失效转移。有关全部详细信息，请参阅 [Apache Kafka 客户端的最佳实践建议](bestpractices-kafka-client.md)。
+ 运行性能测试，验证客户端配置是否允许用户即使在峰值负载下重启代理时，也能实现性能目标。您可以从 MSK 控制台或使用 MSK 重启集群中的代理。 APIs

## 服务器端注意事项
<a name="bestpractices-server-consideration"></a>

**Topics**
+ [调整集群的大小：每个集群的代理数量](#brokers-per-express-cluster)
+ [监控 CPU 使用率](#bestpractices-monitor-cpu-express)
+ [调整集群的大小：每个快速代理的分区数量](#partitions-per-express-broker)
+ [监控连接数](#monitor-connection-count)
+ [重新分配分区](#bestpractices-express-reassign-partitions)

### 调整集群的大小：每个集群的代理数量
<a name="brokers-per-express-cluster"></a>

为基于快速代理的集群选择代理数量非常简单。每个快速代理都有定义的入口和出口吞吐能力。应使用这种吞吐能力作为调整集群大小的主要手段（然后考虑分区和连接数等其他因素，如下所述）。

例如，如果您的流媒体应用程序需要 45 MBps % 的数据入口（写入）和 90 MBps 个数据出口（读取）容量，则只需使用 3 个 express.m7g.large 代理即可满足您的吞吐量需求。每个 express.m7g.large 代理将处理 15 个入口和 30 个 MBps 出口。 MBps 有关每个快速代理大小的建议吞吐量限制，请参阅下表。如果吞吐量超过建议的限制，您可能会遇到性能下降的情况，因此应减小流量或扩展集群。如果吞吐量超过建议的限制并达到每个代理的配额，MSK 会限制客户端流量以免进一步过载。

您还可以查看 [MSK 大小和定价](https://view.officeapps.live.com/op/view.aspx?src=https%3A%2F%2Fdy7oqpxkwhskb.cloudfront.net%2FMSK_Sizing_Pricing.xlsx&wdOrigin=BROWSELINK)电子表格来评估多种场景，并考虑分区数等其他因素。

下表列出了各个实例大小的每个代理的建议最大吞吐量。


| 实例大小 | 入口 () MBps | 出口 () MBps | 
| --- | --- | --- | 
|  `express.m7g.large`  | 15.6 | 31.2 | 
|  `express.m7g.xlarge`  | 31.2 | 62.5 | 
|  `express.m7g.2xlarge`  | 62.5 | 125.0 | 
|  `express.m7g.4xlarge`  | 124.9 | 249.8 | 
|  `express.m7g.8xlarge`  | 250.0 | 500.0 | 
|  `express.m7g.12xlarge`  | 375.0 | 750.0 | 
|  `express.m7g.16xlarge`  | 500.0 | 1000.0 | 

### 监控 CPU 使用率
<a name="bestpractices-monitor-cpu-express"></a>

建议将代理的总 CPU 利用率（定义为 CPU 用户 \$1 CPU 系统）保持在 60% 以下。当集群的总 CPU 可用率至少达到 40% 时，Apache Kafka 可以在必要时在集群中的代理之间重新分配 CPU 负载。由于计划内或计划外事件，可能需要这么做。计划内事件的一个示例是集群版本升级，在此期间，MSK 通过逐一重启来更新集群中的代理。计划外事件的一个示例是代理硬件故障，最坏的情况是可用区故障，可用区中的所有代理都因此受到影响。当具有分区领导副本的代理离线时，Apache Kafka 会重新分配分区领导权，以将工作重新分配给集群中的其他代理。通过遵循此最佳实践，您可以确保集群中有足够的 CPU 余量来容忍此类操作事件。

您可以使用*亚马逊 CloudWatch 用户指南*中的将[数学表达式与 CloudWatch 指标结合使用](https://docs.aws.amazon.com///AmazonCloudWatch/latest/monitoring/using-metric-math.html)来创建复合指标，即 CPU 用户 \$1 CPU 系统。设置当复合指标达到 60% 的平均 CPU 利用率时触发的警报。触发此警报时，请使用以下选项之一扩展集群：
+ 选项 1：[将您的代理大小更新](msk-update-broker-type.md)为下一个较大的大小。请记住，当您更新集群中的代理大小时，Amazon MSK 会以滚动方式使代理离线，并暂时将分区领导权重新分配给其他代理。
+ 选项 2：[通过添加代理来扩展集群](msk-update-broker-count.md)，然后使用名为 `kafka-reassign-partitions.sh` 的分区重新分配工具来重新分配现有分区。

**其他建议**
+ 作为负载分配的代理，监控每个代理的 CPU 总利用率。如果代理的 CPU 利用率一直不均衡，则可能表明集群内的负载分布不均。我们建议使用 [Cruise Control](cruise-control.md)，通过分区分配持续管理负载分配。
+ 监控生成和使用延迟。生成和使用延迟会随着 CPU 利用率呈线性增加。
+ JMX 抓取间隔：如果您使用 Prometheus 功能启用开源监控系统，则建议您为 Prometheus 主机配置 (`prometheus.yml`) 使用 60 秒或更长的抓取间隔 (`scrape_interval: 60s`)。降低抓取间隔可能会导致集群上的 CPU 使用率过高。

### 调整集群的大小：每个快速代理的分区数量
<a name="partitions-per-express-broker"></a>

如果遇到高分区、低吞吐量的用例，即分区数较高，但各分区之间没有发送流量，则每个代理可以打包多个分区，前提是您已进行了充分的测试和性能测试，证实集群在较高分区数下仍保持正常。如果每个代理的分区数量超过允许的最大值，并且您的集群过载，将会阻止您执行以下操作：
+ 更新集群配置
+ 将集群更新为较小的代理大小
+ 将 AWS Secrets Manager 密钥与具有 SASL/SCRAM 身份验证的集群关联

集群过载大量分区也可能导致在 Prometheus 抓取 CloudWatch 和抓取时缺少 Kafka 指标。

有关选择分区数的指导，请参阅 [Apache Kafka 支持每个集群 20 万个分区](https://blogs.apache.org/kafka/entry/apache-kafka-supports-more-partitions)。我们还建议您执行自己的测试，以确定适合您代理的大小。有关不同代理大小的更多信息，请参阅[Amazon MSK 代理大小](broker-instance-sizes.md)。

有关每个快速代理的建议分区数量（包括领导副本和跟随者副本），请参阅[快速代理的分区配额](limits.md#msk-express-broker-partition-quota)。建议分区数量不是强制执行的，对于跨预置主题分区发送流量的场景，这是最佳的做法。

### 监控连接数
<a name="monitor-connection-count"></a>

客户端连接至代理会消耗内存和 CPU 等系统资源。根据身份验证机制，应实施监控以确保在适用的限制范围内。要处理连接失败时的重试，可以在客户端设置 `reconnect.backoff.ms` 配置参数。例如，如果您希望客户端在 1 秒钟后重试连接，请将 `reconnect.backoff.ms` 设置为 `1000`。有关配置重试次数更多信息，请参阅 [Apache Kafka 文档](bestpractices-kafka-client.md#bestpractices-kafka-client-client-availability)。


****  

| 维度 | 配额 | 
| --- | --- | 
|  每个代理的最大 TCP 连接数（[IAM 访问控制](iam-access-control.md)）  | 3000 | 
|  每个代理的最大 TCP 连接数 (IAM)  | 每秒 100 个 | 
|  每个代理的最大 TCP 连接数（非 IAM）  | MSK 不对非 IAM 身份验证强制执行连接限制。但应监控 CPU 和内存使用量等其他指标，以确保不会因为连接数过多而导致集群过载。 | 

### 重新分配分区
<a name="bestpractices-express-reassign-partitions"></a>

要将分区移动到同一预置 MSK 集群上的不同代理，您可以使用名为 `kafka-reassign-partitions.sh` 的分区重新分配工具。为了安全操作，建议一次调用 `kafka-reassign-partitions` 时重新分配的分区数不要超过 20 个。例如，在添加新代理以扩展集群或移动分区以移除代理之后，您可以通过将分区重新分配给新代理来重新平衡该集群。有关如何向预置 MSK 集群添加代理的信息，请参阅[扩展 Amazon MSK 集群中的代理数量](msk-update-broker-count.md)。有关如何从预置 MSK 集群中移除代理的信息，请参阅[从 Amazon MSK 集群中移除代理](msk-remove-broker.md)。有关分区重新分配工具的信息，请参阅 Apache Kafka 文档中的[扩展集群](https://kafka.apache.org/documentation/#basic_ops_cluster_expansion)。