Kafka的topic的partitions数的选取

如何确定topic需要多少个partition

一般情况是数据吞吐决定，这里的吞吐的单位是MB/s，这里暂时不考虑kafka服务端的单partition的吞吐瓶颈，而是考虑Producer和Consumer两端的吞吐

Producer

生产者的吞吐和以下几个配置有关：

1. batching size
2. compression codec
3. acks
4. replication factor

一般情况下，一个Producer的吞吐在10MB/s左右

Consumer

Consumer的吞吐和用户逻辑强相关，所以需要consumer的业务逻辑实现方来评估consumer的吞吐能力

确定partition数目

Given:

1. p : producer throughput in MB/S
2. c : consumer throughput in MB/s
3. t : overall throughtput in MB/s

Result:

       NumOfPartition = max(t/p, t/c)

动态增加partitions

Partition是可以动态增加的，但是需要尽量在业务接入最初，对parttion数目做准确评估，因为不是所有的业务场景都适合做动态增加Partition数目操作。 对于Keyed messge， 可以配置消息会按照key的hash值做partition的路由，这也保证了相同的key的消息的消费是保序的。如果动态增加partition数目，可能会导致乱序问题。 对于这样的业务场景，一个安全的扩容方案是先停掉所有的producer， consumer全部消费完数据后，再做 add partition操作，然后在恢复producer的写入

partition数目过多带来的问题

1. 增加open file handles
2. 增加Broker宕机恢复时间
3. 增加延迟

对每台Broker来说，partition的数目不应该超过 100 * (num of brokers in cluster) * (replication-factor), 对于个10台broker，replication-factor=2的集群，单机partition的数目不应该超过 2000个~

结论

确定topic的一个合适的partition数目很重要，太少了， producer或者consumer会出现读写平静，太多了，会引起其他问题

引用：https://www.jianshu.com/p/8c07039437d0
原文：https://www.confluent.io/blog/how-choose-number-topics-partitions-kafka-cluster/