标签：必须 压缩 改善 窗口 ons 管理 led logging 改进
之前网上关于确定Kafka分区数的博客多多少少都源自于饶军大神的文章，如今他带来了这方面的第二篇文章，特此翻译一下，记录一下其中的要点。
原贴地址： https://www.confluent.io/blog/apache-kafka-supports-200k-partitions-per-cluster
Kafka中topic可以设置多个分区，而分区是最小的并行度单位。通常而言，分区数越多吞吐量也越高。但是依然有很多因素制约了一个Kafka集群所能支持的最大分区数。我现在高兴地宣布Kafka 1.1.0版本在这方面取得了重大的改进。目前生产环境中单Kafka集群支持的分区上限得到了极大的提升。
为了便于理解这个改进是如何实现的，我们重温一下分区leader和controller的基本概念。首先，每个分区都可以配置多个副本用于实现高可用性以及持久性。其中的一个副本被指定为leader而所有client只与leader进行交互；其次，cluster中的某个broker被指定为controller来管理整个集群。若broker挂掉，controller负责为该broker上所有分区选举leader。
默认情况下关闭Kafka broker执行的是一个受控关闭操作（下称controlled shutdown）。Controlled shutdown对client的影响是最小的。一个典型的controlled shutdown分为以下几步：1. 发送SIGTERM信号给待关闭的broker；2. Broker发送请求给controller表明自己要正常关闭；3. Controller变更该broker上所有分区的leader并将这部分数据保存回Zookeeper；4. Controller发送新的leader信息给其他broker；5. Controller发送响应给关闭中的broker表明操作成功，于是broker成功关闭。此时，client端不受任何影响因为新leader已经转移到其他broker上。下面的两张图描述了这个过程，注意到图中(4)和(5)步是可以并行执行的：
上图中步骤(1)发起broker关闭；步骤(2)发送controlled shutdown请求给controller；步骤(3)中controller写入新leader到Zookeeper；步骤(4)controller发送新leader信息到其他broker；步骤(5)controller发送成功信息给关闭中的broker
在Kafka 1.1.0之前，一旦发起controlled shutdown，controller每次只能为一个分区选举leader。对于每个分区而言，controller顺序执行：选择新leader、同步写leader信息回Zookeeper以及同步leader信息给其他broker等操作。这种设计是低效率的：首先，同步写入Zookeeper就有很高的延时，从而整体拖慢controller shudown时间；其次，每次处理一个分区的做法导致需要给其他broker发送很多次请求，即使这些请求本身携带的数据量是很小的，从而最终导致对新leader的处理时间被极大地拉长。
Kafka 1.1.0为controlled shutdown引入了多个方面的性能提升。第一个提升就是使用异步API来替代了之前的同步写入Zookeeper。在controlled shutdown过程中，Kafka不再是每次写入一个leader信息，等待其完成然后再写入下一个。相反地，controller使用异步API一次性地提交多个分区的leader到Zookeeper上，然后统一等待其执行完毕。这就等于在Kafka与Zookeeper之间构建了一种管道式请求处理流程，从而减少了整体的延时。第二个提升则是将于新leader的交互操作批量化。与其每次为一个分区发送RPC请求，controller使用单个RPC请求一次性地携带所有受影响分区的leader信息。
同时，Kafka对于controller failover的时间也做了优化。当controller挂掉后，Kafka集群自动检测controller失败并选择其他broker作为新的controller。在开启controller工作之前，新选出的controller必须要从Zookeeper中加载所有分区的状态信息到内存中。如果controller直接崩溃的话，分区不可用的时间窗口将等同于Zookeeper会话超时时间加上controller状态加载时间，所以降低加载时间能够有效地帮助我们改善Kafka可用性。在1.1.0之前，加载操作使用的也是同步Zookeeper API。在1.1.0中被替换成了异步API。
社区对controlled shutdown时间和加载时间都做了测试。每个测试都使用了5节点Zookeeper的集群。在测试controlled shutdown时，社区搭建了一个5节点broker的Kafka集群并为该集群创建了25000个单分区的topic，每个topic都是双副本，故每个broker上平均有10000个分区。之后测试controlled shutdown，测试结果如下：
提升的很大一部分来自于修复了打日志(logging)的开销：之前在每个分区leader变更时都会记录集群中所有分区的数据——这实际上是没必要的。通过修复了这个logging的bug，controller shutdown从6.5分钟被压缩到30秒，而采用异步API更进一步地将其拉低到3秒。这些提升都极大地缩短了Kafka集群重启恢复的时间。
在第二项测试中，社区同样搭建了一个5节点集群，只不过这次创建了2000个配置有50分区的topic，单副本——故总数是1000000个分区。当测试controller状态加载时间时发现比1.0.0有了100%的提升（1.0.0耗时28秒，1.1.0耗时14秒）。
有了这些提升，Kafka单集群能够支持多少分区呢？确切的数字自然依赖于诸如可容忍的不可用窗口时间、Zookeeper延时、broker存储类型等因素。根据经验法则我们评估单台broker能够支撑的分区数可达4000个，而单集群能够支撑200000个分区。当然后者主要受限于集群对controller崩溃这种不常见情形的容忍度，另外其他影响分区数的因素也要考虑进来。
1.1.0所做的改进仅仅是提升Kafka高扩展性的一小步。事实上社区在1.1.0版本还尝试了更多的分区并改进了它们的延时表现。后面可能会在另一篇文章中给出具体的说明。在未来，Kafka社区计划实现单集群支撑百万级分区的构想，所以，敬请期待~~
标签：必须 压缩 改善 窗口 ons 管理 led logging 改进
原文地址：https://www.cnblogs.com/huxi2b/p/9984523.html
