一、实际分区过多弊端：

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过大过多，对可用性和消息延迟带负面影响