kafka分区数和吞吐量的关系

分区(partition)概念

要讲 kafka 分区数和吞吐量的关系，首先得理解什么是分区(partition)。

Partition是作用于具体的Topic而已的，而不是一个独立的概念。Partition能水平扩展客户端的读写性能，是高吞吐量的保障。通俗的讲，Partition就是一块保存具体数据的空间，本质就是磁盘上存放数据的文件夹，所以Partition是不能跨Broker存在的，也不能在同一个Broker上跨磁盘。对于一个Topic，可以根据需要设定Partition的个数。数据持久化时，每条消息都是根据一定的分区规则路由到对应的Partition中，并append在log文件的尾部(这一点类似于HDFS)，如上图；在同一个Partition中消息是顺序写入的且始终保持有序性；但是不同Partition之间不能保证消息的有序性(高吞吐量的保障)。kafka就是通过使用分区的设计将topic的消息打散到多个分区分布保存在不同的broker上，实现了producer和consumer消息处理的高吞吐量。

吞吐量关系

在kafka中，Partition并不是最小的数据存储单元。Partition下还可以细分成Segment，每个Partition是由一个或多个Segment组成。但patition是kafka并行操作的最小单元。在producer和broker端，向每一个分区写入数据是可以完全并行化的，此时，可以通过加大硬件资源的利用率来提升系统的吞吐量，例如对数据进行压缩。在consumer端，kafka只允许单个partition的数据同时被一个consumer线程消费。因此，在consumer端，每一个Consumer Group内部的consumer并行度完全依赖于被消费的分区数量。因此，通常情况下，在一个 Kafka 集群中，partition的数量越多，意味着可以到达的吞吐量越大。

我们可以粗略地通过吞吐量来计算kafka集群的分区数量。假设对于单个partition，producer端的可达吞吐量为 p，Consumer端的可达吞吐量为 c，期望的目标吞吐量为 t，那么集群所需要的partition数量至少为max(t/p,t/c)。在producer端，单个分区的吞吐量大小会受到批量大小、数据压缩方法、确认类型（同步/异步）、复制因子等配置参数的影响。经过测试，在producer端，单个partition的吞吐量通常是在 10MB/s 左右。在consumer端，单个partition的吞吐量依赖于consumer端每个消息的应用逻辑处理速度。因此，我们需要对consumer端的吞吐量进行测量。

分区扩展

虽然随着时间的推移，我们能够对分区的数量进行添加，但是对于基于Key来生成的这一类消息不太一样。当producer向kafka写入基于key的消息时，kafka通过key的hash值来确定消息需要写入哪个具体的分区。通过这样的方案，kafka能够确保相同key值的数据可以写入同一个partition。kafka的这一能力对于一部分顺序要求的业务应用是极为重要的，例如对于同一个key的所有消息，consumer需要按消息的顺序进行有序消费。如果partition的数量发生改变，那么上面的有序性保证将不复存在。为了避免上述情况发生，通常的解决办法是多分配一些分区，以满足未来的需求。

此外，我们还可以基于当前的业务吞吐量为kafka集群分配较小的broker数量，随着业务增长，再向集群中增加更多的broker，然后将适当比例的partition迁移到新增加的broker中去（迁移可以参考我之前的文章）。通过这样的方法，可以在满足各种应用场景（包括基于key消息的场景）的情况下，保持业务吞吐量的扩展性。

在规划分区数时，除了吞吐量，还有一些其他因素值得考虑，后续再聊。