Kafka 主题最重要的一个功能是可以让消费者指定它们想要消费的消息子集。在极端情况下,将所有数据放在同一个主题中可能不是一个好主意,因为这样消费者就无法选择它们感兴趣的事件——它们需要消费所有的消息。另一种极端情况,拥有数百万个不同的主题也不是一个好主意,因为 Kafka 的每个主题都是有成本的,拥有大量主题会损害性能。
实际上,从性能的角度来看,分区数量才是关键因素。在 Kafka 中,每个主题至少对应一个分区,如果你有 n 个主题,至少会有 n 个分区。不久之前,Jun Rao 写了一篇博文,解释了拥有多个分区的成本(端到端延迟、文件描述符、内存开销、发生故障后的恢复时间)。根据经验,如果你关心延迟,那么每个节点分配几百个分区就可以了。如果每个节点的分区数量超过成千上万个,就会造成较大的延迟。
关于性能的讨论为设计主题结构提供了一些指导:如果你发现自己有数千个主题,那么将一些细粒度、低吞吐量的主题合并到粗粒度主题中可能是个明智之举,这样可以避免分区数量蔓延。
然而,性能并不是我们唯一关心的问题。在我看来,更重要的是主题结构的数据完整性和数据模型。我们将在本文的其余部分讨论这些内容。
主题等于相同类型事件的集合?
人们普遍认为应该将相同类型的事件放在同一主题中,不同的事件类型应该使用不同的主题。这种思路让我们联想到关系型数据库,其中表是相同类型记录的集合,于是我们就有了数据库表和 Kafka 主题之间的类比。
Confluent Avro Schema Registry 进一步强化了这种概念,因为它鼓励你对主题的所有消息使用相同的 Avro 模式(schema)。模式可以在保持兼容性的同时进行演化(例如通过添加可选字