Kafka高吞吐量，就是通过partition将topic中消息存到Kafka集群不同broker中。partition并行度调优最小单元
理论分区越多，吞吐量就越大。
一、实际分区过多弊端：
1、客户端/服务器端需内存就越多
1）Kafka0.8.2后，producer参数batch.size(默认16KB)，为每个分区缓存消息，积累一定大小或时间，移除发往broker。分区多，内存占用多
2）consumer消费线程数也增加。如10000个分区，创建10000个线程，创建大约10000个Socket获取分区数据。线程的开销成本高
3——服务器端缓存成本大，服务器端维护controller，FetcherManager等
2、文件句柄的开销
broker每个partition对应磁盘一个目录。每个日志数据分配索引和数据文件。打开index文件句柄和数据文件句柄。partition多，句柄数也多，超过操作系统文件句柄数量限制
3、能增加端对端的延迟
延迟时间：producer发送 到 consumer接收时间
1）问题原因：producer消息提交后暴露。例，所有in-sync副本同步复制完才暴露。复制时间是延迟最原因。默认broker只分配一个线程复制。
2）解决：增大kafka集群缓解。例，1000个分区leader放1个/10个broker节点，延迟差异。每个broker节点平均处理100个分区，数十毫秒变几毫秒
3)根据经验，b个broker节点和复制因子r，整个kafka集群partition数量<=100*b*r个，即单partition的leader<=100。
4、降低高可用性
partition多个副本，在不同broker，一个leader，其他follower
1）集群自动化管理副本，通过leader确保同步。broker故障里面partition暂不可用。controller节点broker自动选leader，接收请求。从zk读和改影响partition元数据信息。
2）broker停止服务前，controller将该broker所有leader一个个移走。从客户层面看，系统在很小时间不可用
3）broker意外停服（kill -9方式)，不可用时间与受影响partition数有关：如2节点集群2000partition，每个2个副本。一个broker宕，1000个partition同时不可用。每个partition 5ms恢复，1000个5秒钟。
4）恢复慢：如controller节点broker宕：选举恢复到新broker不启动，自动错误恢复，但新的controller要从zk中读每个partition元数据用于初始化数据。partition多不可用时间长
总之，partition多带高吞吐量。但partition过大过多，对可用性和消息延迟带负面影响
二、如何确定合理分区数？
partition均衡负载是吞吐量关键，根据生产和消费者目标吞吐量估计。
测试topic的producer和consumer吞吐量，Tp和Tc，MB/s。目标吞吐量Tt，numPartitions = Tt / max(Tp, Tc)
https://mp.weixin.qq.com/s/0EGp8V_OwbU47nHCzUWLuA
