如何确定分区数量

遵循一定的步骤来尝试确定分区数

创建一个只有1个分区的topic，然后测试这个topic的producer吞吐量和consumer吞吐量。假设它们的值分别是Tp和Tc，单位可以是MB/s。然后假设总的目标吞吐量是Tt，那么分区数 =  Tt / max(Tp, Tc)

说明：Tp表示producer的吞吐量。测试producer通常是很容易的，因为它的逻辑非常简单，就是直接发送消息到Kafka就好了。Tc表示consumer的吞吐量。测试Tc通常与应用的关系更大， 因为Tc的值取决于你拿到消息之后执行什么操作，因此Tc的测试通常也要麻烦一些。

使用压测工具，得出最佳分区数

kafka官方也提供了脚本方便我们针对我们的kafka集群做测试，我们可以测试当前提供的硬件条件进行压测，得出当前机器环境到底能支持多少分区数，从而达到尽量最优的方案。

生产者性能测试脚本：kafka-producer-perf-test.sh

消费者性能测试脚本：kafka-consumer-perf-test.sh

设置好topic的某个分区数，之后我们可以选择不同的参数：比如消息发送总量、单条消息大小、吞吐量、acks、消费线程数等等，这样压测之后就能得出一份测试报告，报告包含的数据有：50%/90%/95%/99%的消息处理耗时、平均处理耗时、每秒消息发送吞吐量、每秒拉取的消息的字节大小/消息数量、消费总数、再平衡时间、按消息计数/消息大小计算的吞吐量等等。

合适的增加分区数是可以提高吞吐量，但超过一定的阈值之后，吞吐量也会随之下降。如果生产上对吞吐量有一定的要求，可以在生产机器硬件条件下进行压测，得出适合你的最优分区数。

一条消息如何知道要被发送到哪个分区？
按照key值分配

默认情况下，Kafka根据传递消息的key来进行分区的分配，即hash(key) % numPartitions：

def partition(key: Any, numPartitions: Int): Int = {
    Utils.abs(key.hashCode) % numPartitions
}

这保证了相同key的消息一定会被路由到相同的分区。key为null时，从缓存中取分区id或者随机取一个。如果你没有指定key，那么Kafka是如何确定这条消息去往哪个分区的呢？



不指定key时，Kafka几乎就是随机找一个分区发送无key的消息，然后把这个分区号加入到缓存中以备后面直接使用——当然了，Kafka本身也会清空该缓存（默认每10分钟或每次请求topic元数据时）。

Consumer个数与分区数有什么关系？

topic下的一个分区只能被同一个consumer group下的一个consumer线程来消费，但反之并不成立，即一个consumer线程可以消费多个分区的数据，比如Kafka提供的ConsoleConsumer，默认就只是一个线程来消费所有分区的数据。



所以，如果你的分区数是N，那么最好线程数也保持为N，这样通常能够达到最大的吞吐量。超过N的配置只是浪费系统资源，因为多出的线程不会被分配到任何分区。

Consumer消费Partition的分配策略

Kafka提供的两种分配策略：range和roundrobin，由参数partition.assignment.strategy指定，默认是range策略。

当以下事件发生时，Kafka 将会进行一次分区分配：

• 同一个 Consumer Group 内新增消费者
• 消费者离开当前所属的Consumer Group，包括shuts down 或 crashes
• 订阅的主题新增分区

将分区的所有权从一个消费者移到另一个消费者称为重新平衡（rebalance），如何rebalance就涉及到本文提到的分区分配策略。
下面我们将详细介绍 Kafka 内置的两种分区分配策略。本文假设我们有个名为 T1 的主题，其包含了10个分区，然后我们有两个消费者（C1，C2）
来消费这10个分区里面的数据，而且 C1 的 num.streams = 1，C2 的 num.streams = 2。

Range strategy

Range策略是对每个主题而言的，首先对同一个主题里面的分区按照序号进行排序，并对消费者按照字母顺序进行排序。在我们的例子里面，排完序的分区将会是0, 1, 2, 3, 4, 5, 6, 7, 8, 9；消费者线程排完序将会是C1-0, C2-0, C2-1。然后将partitions的个数除于消费者线程的总数来决定每个消费者线程消费几个分区。如果除不尽，那么前面几个消费者线程将会多消费一个分区。在我们的例子里面，我们有10个分区，3个消费者线程， 10 / 3 = 3，而且除不尽，那么消费者线程 C1-0 将会多消费一个分区，所以最后分区分配的结果看起来是这样的：
 

• C1-0 将消费 0, 1, 2, 3 分区
• C2-0 将消费 4, 5, 6 分区
• C2-1 将消费 7, 8, 9 分区

假如我们有11个分区，那么最后分区分配的结果看起来是这样的：
 

• C1-0 将消费 0, 1, 2, 3 分区
• C2-0 将消费 4, 5, 6, 7 分区
• C2-1 将消费 8, 9, 10 分区

假如我们有2个主题(T1和T2)，分别有10个分区，那么最后分区分配的结果看起来是这样的：
 

• C1-0 将消费 T1主题的 0, 1, 2, 3 分区以及 T2主题的 0, 1, 2, 3分区
• C2-0 将消费 T1主题的 4, 5, 6 分区以及 T2主题的 4, 5, 6分区
• C2-1 将消费 T1主题的 7, 8, 9 分区以及 T2主题的 7, 8, 9分区

可以看出，C1-0 消费者线程比其他消费者线程多消费了2个分区，这就是Range strategy的一个很明显的弊端。

RoundRobin strategy

使用RoundRobin策略有两个前提条件必须满足：

同一个Consumer Group里面的所有消费者的num.streams必须相等；

每个消费者订阅的主题必须相同。

所以这里假设前面提到的2个消费者的num.streams = 2。RoundRobin策略的工作原理：将所有主题的分区组成 TopicAndPartition 列表，然后对 TopicAndPartition 列表按照 hashCode 进行排序，看下面的代码应该会明白：



最后按照round-robin风格将分区分别分配给不同的消费者线程。

在这个的例子里面，假如按照 hashCode 排序完的topic-partitions组依次为T1-5, T1-3, T1-0, T1-8, T1-2, T1-1, T1-4, T1-7, T1-6, T1-9，我们的消费者线程排序为C1-0, C1-1, C2-0, C2-1，最后分区分配的结果为：

• C1-0 将消费 T1-5, T1-2, T1-6 分区；
• C1-1 将消费 T1-3, T1-1, T1-9 分区；
• C2-0 将消费 T1-0, T1-4 分区；
• C2-1 将消费 T1-8, T1-7 分区；

多个主题的分区分配和单个主题类似。遗憾的是，目前我们还不能自定义分区分配策略，只能通过partition.assignment.strategy参数选择 range 或 roundrobin。