Amazon MSK 主题分区数选择指南

刚接触Amazon Managed Streaming for Apache Kafka（Amazon MSK）的客户经常问他们的主题需要多少个分区。选择正确的分区数量是你做出的最具影响力的架构决策之一，因为它直接影响吞吐量、可扩展性和运维复杂性。

在Apache Kafka中，主题是对数据流进行分类的基本单元，但为了实现高可扩展性和性能，Kafka 将主题分割成更小、独立的单元，称为分区。

在本文中，我们为你的用例确定理想分区数量提供实用指导。

了解 Kafka 分区

在Apache Kafka中，分区是存储和并行的单元。每个分区是一个有序、不可变的日志，可以存储生产到主题的记录。当你创建主题时，Kafka 将其分区分布到集群中的代理上。分区允许 Kafka 在三个关键方面进行扩展：

• 并行性 – 在消费者组内，每个分区在同一时间只能由一个消费者读取。每个分区对应代理存储中一个专用的日志文件，Kafka 通过独立的处理线程管理这些日志。这种架构允许更多的分区支持更多的消费者并行处理数据，每个分区的日志独立管理读写操作。

下图展示了 Kafka 如何在三个代理的集群中分布分区副本，每个代理既是某些分区的领导者，也是其他分区的跟随者。

图 1：分区副本分布在三个代理的集群中

下图说明了生产者如何将新记录追加到分区日志的末尾，而消费者则从当前偏移位置顺序读取。

图 2：两个分区日志中的生产者写入和消费者偏移位置

• 吞吐量 – 生产者和消费者可以在分区之间并行读写数据，从而提高整体吞吐量。
• 可扩展性 – 分区允许 Kafka 将数据和负载分散到多个代理上，而不是集中在一个节点上。

然而，增加分区数量也有权衡。每个分区都会增加元数据开销、消耗内存，并且需要代理上的文件句柄。虽然更多分区提高了吞吐量和并行性，但它们也增加了集群的运维负担。分区过多可能导致代理故障期间的领导者选举时间更长、端到端延迟增加，以及生产者和消费者管理多个分区连接的内存消耗更高。

选择分区数量时的权衡

选择分区数量是在并行性和资源利用之间取得平衡的行为。

更多分区的好处

使用更多分区可以通过允许 Kafka 将读写流量分布到更多代理上来显著提高吞吐量。这对于高容量摄取管道和实时分析工作负载特别有用。更多分区还允许消费者组水平扩展，因为组中活动消费者的最大数量受分区数量的限制。此外，选择可被代理数量整除的分区数量有助于实现均衡的领导权和副本分布，降低负载不均的风险。

更多分区的运维成本

然而，更高的分区数量也带来成本。当代理发生故障或进行维护时，Kafka 必须对每个受影响的分区执行恢复操作。在恢复期间，Kafka 为不可用代理上托管的分区选举新的领导者，并从剩余的同步副本中将数据复制到新分配的代理。这个过程涉及通过网络复制分区数据以恢复复制因子，这可能占用大量资源。随着分区数量的增加，这些恢复操作需要更长的时间，因为每个分区都需要自己的领导者选举和数据复制周期。

你可能会遇到分区数量非常高的集群，在滚动升级期间经历长时间恢复，即使总体流量适中。Amazon MSK Express 代理通过恢复速度快 90 倍，并在扩展集群时提供 180 倍的弹性，解决了这一挑战。这显著减少了高分区数量在维护窗口和故障场景中的运维影响。

基础设施成本影响

除了运维复杂性，更多分区还会直接增加基础设施成本。Amazon MSK 发布每代理分区限制因实例类型而异。当总分区数（包括副本）超过当前代理集群能支持的范围时，你必须添加代理以保持在推荐限制内，即使仅凭吞吐量并不需要额外的容量。

Amazon MSK 每代理分区指南

Amazon MSK 发布推荐的每代理分区指南，以帮助你可靠地操作集群。这些值是严格限制。超过它们可能导致操作困难，特别是在代理替换或滚动升级期间，并可能阻止集群操作，如配置更新或缩减。

Express 代理相比 Standard 代理支持每个代理最多 5 倍的分区。例如，最大的 Standard 代理（kafka.m7g.16xlarge）支持推荐的最大每代理 4,000 个分区。等效的 Express 代理（express.m7g.16xlarge）支持最多 20,000 每代理推荐分区。这种更高的分区密度意味着受分区限制的工作负载可以托管在更少的代理上，从而将此类工作负载的性价比提高最多 50%。

我们建议设置Amazon CloudWatch 告警 PartitionCount 每代理指标，以主动监控您的分区分布。当告警触发时，评估您的分区策略，并考虑在代理之间重新平衡分区、整合主题或扩展集群以保持在建议限制内。有关详细指导，请参阅 调整集群规模：每个标准代理的分区数 和 Express 代理分区配额.

选择分区数的实用指南

没有适用于每个 Kafka 工作负载的单一公式。在实践中，您在确定分区大小时通常会结合多种考虑因素。

• 从吞吐量要求开始 – 第一步是确定您的每分区吞吐量容量，这决定了您需要多少个分区。

对于 Express 代理，请使用每代理吞吐量容量作为集群扩展的主要依据。Express 代理具有完全托管的存储层，因此您无需单独考虑存储 I/O 限制。已发布的每代理限制 代表您的工作负载可用的有效容量。对于标准代理，可实现的吞吐量取决于代理实例大小之外的其他因素。这些因素包括预置的 EBS 存储吞吐量、从代理读取的消费者组数量，以及从内存与磁盘提供的数据量。当生产者写入、代理之间复制数据以及消费者读取不在内存中的数据时，会消耗存储 I/O。因此，请通过环境中的负载测试来验证标准代理的有效每分区吞吐量。一旦您知道每分区吞吐量，即可计算所需的分区数：分区数 = 主题的峰值吞吐量 ÷ 每分区吞吐量 例如，如果一个主题在峰值时必须处理 40 MB/秒，而您的测试显示每个分区可以维持 5 MB/秒，那么您需要：40 ÷ 5 = 8 个分区。始终通过负载测试验证这些假设，因为实际吞吐量会因工作负载特征而异。对于初始规模估算，请参阅 Amazon MSK 规模和定价工作表 和 Amazon MSK 最佳实践文档。

• 考虑您的消费者并行需求 – 如果您知道高峰处理时间内所需的消费者数量，则使用该数量作为您的分区数。我们建议消费者组中活动的消费者数不要超过分区数。例如，如果您有 5 个分区，则只有 5 个消费者可以主动处理数据。额外的消费者保持空闲。这些空闲消费者仍会与代理保持活动的 TCP 连接，频繁发送心跳和组协调请求。这可能会导致代理资源上的不必要开销，并在出口流量较低的情况下导致高 CPU 使用率。

图 3：当消费者组中的消费者数量多于分区数时，空闲消费者

• 生产者的吞吐量和分区键 – 在确定分区大小时，除了消费者并行性之外，还要考虑生产者端的吞吐量。如果生产者生成数据的速度超过单个分区可处理的速度，额外的分区有助于在代理之间分配写入流量。分区键也起着关键作用。分布不均或基数低的键可能会造成热点分区并限制吞吐量。在这种情况下，除非记录均匀分布，否则仅增加分区数并不能提高吞吐量。
• 规划均匀分布和未来增长 – 当分区能够在代理之间均匀分布时，Kafka 表现最佳。不要专注于具体数字，而应选择在预期代理数量上能良好整除的分区数。这减少了添加或替换代理时的重新分配变动。但避免过度分区。为未来增长留出一些余量是合理的。然而，"以防万一"创建数千个分区通常弊大于利。以后增加分区是支持的，但可能会影响顺序保证，并可能需要消费者更改。从一个保守的数目开始，监控实际流量模式，并逐步扩展。

从操作角度来看，Amazon MSK 根据代理实例类型提供了建议的 每代理分区 指南。超过这些指南会增加操作风险，并可能阻止集群操作，如版本升级、扩展或配置更改。大量分区还可能增加消费者组重新平衡的持续时间，暂时暂停消息处理并增加端到端延迟。

请记住，分区可以提高可扩展性，但不能解决应用程序级别的瓶颈，如消费缓慢、低效的处理逻辑或下游系统限制。

结论

为 Amazon MSK 主题确定正确的分区数是一项基础设计决策。它影响 Kafka 集群的吞吐量、可扩展性、故障恢复和日常可操作性。首先要了解您的吞吐量和消费者并行需求，遵守 Amazon MSK 每代理分区指南，避免过度分区，并通过负载测试验证假设。最重要的是，没有普遍"正确"的数字，只有适合您的工作负载、运营目标和成本的数字。

有关更多信息，请参阅 Amazon MSK 开发人员指南 和 Amazon MSK 推荐的最佳实践。