前言
翻译加整理~
How to choose the number of topics/partitions in a Kafka cluster
如何确定Topic需要多少个Partitions
一般情况是数据吞吐决定，这里的吞吐的单位是MB/s，这里暂时不考虑kafka服务端的单partition的吞吐瓶颈，而是考虑Producer和Consumer两端的吞吐
Producer
生产者的吞吐和以下几个配置有关：
- batching size
- compression codec
- acks
- replication factor
一般情况下，一个Producer的吞吐在10MB/s左右
Consumer
Consumer的吞吐和用户逻辑强相关，所以需要consumer的业务逻辑实现方来评估consumer的吞吐能力
确定partition数目
Given:
- p : producer throughput in MB/S
- c : consumer throughput in MB/s
- 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数目过多带来的问题
- 增加open file handles
- 增加Broker宕机恢复时间
- 增加延迟
对每台Broker来说，partition的数目不应该超过 100 * (num of brokers in cluster) * (replication-factor), 对于个10台broker，replication-factor=2的集群，单机partition的数目不应该超过 2000个~
结论
确定Topic的一个合适的Partition数目很重要，太少了， producer或者consumer会出现读写平静，太多了，会引起其他问题
参考文章
How to choose the number of topics/partitions in a Kafka cluster
