一个场景：
Kafka broker如果出现分区不可用，默认会进行受控关闭，以最大限度地减少对客户的服务中断。
一次受控关闭（controlled shutdown）的过程：
发送一个关闭信号给要被shutdown的brocker，将这个broker上的所有分区选出新的leader（从别的broker上的follower中）
kafka1.1.0之前的版本，一次改变一个分区 ：
1.控制器为将被shutdown的brocker的一个分区选一个新的leader，发送信息给zookeeper
2.zookeeper将更新后的leader信息持久化
3.控制器通过发送一个远程请求将被选择的另一个broker上原本是follower的分区变成leader。
第1步和第2步是同步的，必须将第2步完成后才能开始第3步并为下一个分区改变leader
1.1.0之后的版本：
Instead of writing the leader for one partition, waiting for it to complete and then writing another one, the controller submits the leader for multiple partitions to ZooKeeper asynchronously and then waits for them to complete at the end. This allows for request pipelining between the Kafka broker and the ZooKeeper server and reduces the overall latency. The second improvement is that the communication of the new leaders is batched. Instead of one remote request per partition, the controller sends a single remote request with the leader from all affected partitions.
我的理解：将上述中第一步和第二步的同步操作变成异步，即为一个分区选完leader后，将信息发送给zookeeper，没有等到zookeeper将新的信息更新完成就返回，为下一个分区改变leader。最后所有的新的分区信息发送完毕，等待zookeeper将所有收到的信息更新完成，最后可以将第3步一次执行给所有受影响的broker。
另一个场景
当要完成第一场景所要完成的过程时，若控制器宕机，需要选一个新的控制器，这时候被选择的新的控制器需要从zookeeper中加载所有broker的信息（zookeeper向控制器发送broker信息）。这个加载过程也可以是异步，从而减少不可用分区对客户端的影响时间。
资料来源：https://www.confluent.io/blog/apache-kafka-supports-200k-partitions-per-cluster