如何为Kafka集群选择合适的主题和分区数量

[attach]1558[/attach] 这是许多Kafka用户提出的常见问题。 这篇文章的目的是解释几个重要的决定因素，并提供一些简单的公式。  

更多的分区提供更高的吞吐量

首先要理解的是，主题分区是Kafka中并行性的单位。 在生产者和代理端，对不同分区的写入可以完全并行完成。 因此，昂贵的操作（例如压缩）可以利用更多的硬件资源。 在消费者方面，Kafka总是将一个分区的数据提供给一个消费者线程。 因此，消费者（在消费者组内）的并行度受所消耗的分区的数量的限制。 因此，一般来说，Kafka集群中的分区越多，吞吐量就越高。 用于选择分区数量的粗略公式基于吞吐量。 你衡量整个，你可以在生产单个分区（称之为P）和消费实现（称为C）。 比方说，你的目标吞吐量吨 。 然后，你需要至少有MAX（T / P，T / C）分区。 人们可以在生产者上实现的每分区吞吐量取决于诸如批处理大小，压缩编解码器，确认类型，复制因子等等的配置。然而，一般来说，可以在10秒的MB /如在此所示单个分区的基准 。 消费者吞吐量通常是与应用相关的，因为它对应于消费者逻辑可以如何快速地处理每个消息。 所以，你真的需要测量它。 虽然可以随着时间增加分区的数量，但是如果使用密钥生成消息，则必须小心。 当发布带密钥的消息时，Kafka基于密钥的散列将消息确定性地映射到分区。 这提供了保证具有相同密钥的消息总是路由到同一分区。 此保证对于某些应用可能是重要的，因为分区内的消息总是按顺序递送给消费者。 如果分区的数量改变，则这样的保证可能不再保持。 为了避免这种情况，一种常见的做法是过度分区。 基本上，您可以根据未来的目标吞吐量确定分区数，比如一两年后。 最初，您可以根据您的当前吞吐量只有一个小的Kafka集群。 随着时间的推移，您可以向集群添加更多代理，并按比例将现有分区的一部分移动到新代理（可以在线完成）。 这样，当使用密钥时，您可以跟上吞吐量增长，而不会破坏应用程序中的语义。 除了吞吐量，还有一些其他因素，在选择分区数时值得考虑。 正如你将看到的，在某些情况下，分区太多也可能产生负面影响。  

更多分区需要打开更多的文件句柄

每个分区映射到broker中文件系统中的目录。 在该日志目录中，每个日志段将有两个文件（一个用于索引，另一个用于实际数据）。 目前，在Kafka中，每个broker打开每个日志段的索引和数据文件的文件句柄。 因此，分区越多，底层操作系统中需要配置打开文件句柄限制的分区越多。 这大多只是一个配置问题。 我们已经看到生产Kafka集群中，运行的每个broker打开的文件句柄数超过30000。  

更多分区可能是不可用性增加

Kafka支持群集内复制 ，它提供更高的可用性和耐用性。 分区可以有多个副本，每个副本存储在不同的代理上。 其中一个副本被指定为领导者，其余的副本是追随者。 在内部，Kafka自动管理所有这些副本，并确保它们保持同步。 生产者和消费者对分区的请求都在领导副本上提供。 当代理失败时，该代理上具有leader的分区变得暂时不可用。 Kafka将自动将那些不可用分区的领导者移动到其他一些副本以继续服务客户端请求。 这个过程由指定为控制器的Kafka代理之一完成。 它涉及在ZooKeeper中为每个受影响的分区读取和写入一些元数据。 目前，ZooKeeper的操作是在控制器中串行完成的。 在通常情况下，当代理被干净地关闭时，控制器将主动地将领导者一次一个地关闭关闭代理。 单个领导者的移动只需要几毫秒。 因此，从客户的角度来看，在干净的代理关闭期间只有一小窗口的不可用性。 然而，当代理不干净地关闭（例如，kill -9）时，所观察到的不可用性可能与分区的数量成比例。 假设代理具有总共2000个分区，每个具有2个副本。 大致来说，这个代理将是大约1000个分区的领导者。 当这个代理不干净失败时，所有这1000个分区完全不能同时使用。 假设为单个分区选择新的领导需要5毫秒。 对于所有1000个分区，选择新的领导将需要5秒钟。 因此，对于一些分区，它们的观察到的不可用性可以是5秒加上检测故障所花费的时间。 如果一个是不幸的，失败的代理可能是控制器。 在这种情况下，选举新领导者的过程将不会开始，直到控制器故障转移到新的代理。 控制器故障转移自动发生，但需要新控制器在初始化期间从ZooKeeper读取每个分区的一些元数据。 例如，如果Kafka集群中有10,000个分区，并且从ZooKeeper初始化元数据每个分区需要2ms，则可以向不可用性窗口添加20多秒。 一般来说，不洁的故障是罕见的。 但是，如果在这种极少数情况下关心可用性，则可能最好将每个代理的分区数限制为两个到四千个，集群中的分区总数限制到几万个。  

更多分区可能会增加端到端延迟

Kafka中的端到端延迟由从生产者发布消息到消费者读取消息的时间来定义。 Kafka仅在提交后向消费者公开消息，即，当消息被复制到所有同步副本时。 因此，提交消息的时间可以是端到端等待时间的显着部分。 默认情况下，对于在两个代理之间共享副本的所有分区，Kafka代理仅使用单个线程从另一个代理复制数据。 我们的实验表明，将1000个分区从一个代理复制到另一个代理可以添加大约20毫秒的延迟，这意味着端到端延迟至少为20毫秒。 这对于一些实时应用来说可能太高。 请注意，此问题在较大的群集上减轻。 例如，假设代理上有1000个分区引导，并且在同一个Kafka集群中有10个其他代理。 剩余的10个代理中的每个仅需要从第一代理平均获取100个分区。 因此，由于提交消息而增加的延迟将仅为几毫秒，而不是几十毫秒。 作为一个经验法则，如果你关心的延迟，它可能是一个好主意，每个经纪人的分区数量限制为100 * b * r，其中b是经纪人在kafka集群的数量和r是复制因子。  

更多分区可能需要更多的内存在客户端

在最新的0.8.2版本，我们汇合到我们平台1.0，我们已经开发出一种更有效的Java生产商。 新生产者的一个好的功能是它允许用户设置用于缓冲传入消息的内存量的上限。 在内部，生产者缓冲每个分区的消息。 在累积了足够的数据或已经过去足够的时间之后，累积的消息从缓冲器中移除并发送到代理。 如果增加分区的数量，消息将在生产者中的更多分区中累积。 所使用的内存总量现在可能超过配置的内存限制。 当这种情况发生时，生产者必须阻止或丢弃任何新的消息，这两者都不是理想的。 为了防止这种情况发生，需要重新配置具有较大内存大小的生产者。 作为经验法则，为了实现良好的吞吐量，应该在生成器中分配至少几十KB的每个分区，并且如果分区的数量显着增加，则调整存储器的总量。 消费者也存在类似的问题。 消费者每个分区获取一批消息。 消费者消耗的分区越多，需要的内存就越多。 然而，这通常只是不是实时的消费者的问题。  

总结

通常，Kafka集群中的更多分区导致更高的吞吐量。 然而，人们不得不意识到在总体上或每个代理中具有过多分区对可用性和等待时间的潜在影响。 在未来，我们计划改进一些限制，使Kafka在分区数方面更具可扩展性。  

翻译原文：https://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/   作者：饶俊