kafka问题汇总

1、Kafka的用途有哪些？使用场景如何？

• 消息系统： Kafka 和传统的消息系统（也称作消息中间件）都具备系统解耦、冗余存储、流量削峰、缓冲、异步通信、扩展性、可恢复性等功能。与此同时，Kafka 还提供了大多数消息系统难以实现的消息顺序性保障及回溯消费的功能。

• 存储系统： Kafka 把消息持久化到磁盘，相比于其他基于内存存储的系统而言，有效地降低了数据丢失的风险。得益于 Kafka 的消息持久化功能和多副本机制，我们可以把 Kafka 作为长期的数据存储系统来使用。

• 流式处理平台： Kafka 不仅为每个流行的流式处理框架提供了可靠的数据来源，还提供了一个完整的流式处理类库，比如窗口、连接、变换和聚合等各类操作。

2、Kafka中的ISR、AR又代表什么？ISR的伸缩又指什么？

分区中的所有副本统称为 AR 。所有与 leader 副本保持一定程度同步的副本（包括 leader 副本在内）组成ISR ，ISR 集合是 AR 集合中的一个子集。

ISR的伸缩：leader 副本负责维护和跟踪 ISR 集合中所有 follower 副本的滞后状态，当 follower 副本落后太多或失效时，leader 副本会把它从 ISR 集合中剔除。如果 OSR 集合中有 follower 副本“追上”了 leader 副本，那么 leader 副本会把它从 OSR 集合转移至 ISR 集合。

默认情况下，当 leader 副本发生故障时，只有 ISR 集合中的副本才有资格被选举为新的 leader。

replica.lag.time.max.ms ： 这个参数的含义是 Follower 副本能够落后 Leader 副本的最长时间间隔，当前默认值是 10 秒。

unclean.leader.election.enable：是否允许 Unclean 领导者选举。开启 Unclean 领导者选举可能会造成数据丢失，但好处是，它使得分区 Leader 副本一直存在，不至于停止对外提供服务，因此提升了高可用性。

3、Kafka中的HW、LEO、LSO、LW等分别代表什么？

• HW 俗称高水位，消费者只能拉取到这个 offset 之前的消息。
• LSO俗称起始偏移量，一般情况下，日志文件的起始偏移量等于第一个日志分段的 baseOffset。
• LEO 标识当前日志文件中下一条待写入消息的 offset，LEO 的大小相当于当前日志分区中最后一条消息的 offset 值加1。
• LW 俗称低水位，代表 AR 集合中最小的 LSO值。副本的拉取请求和删除消息请求都有可能促使 LW 的增长。

4、Kafka中是怎么体现消息顺序性的？

在Kafka中，只保证Partition(分区)内有序，不保证Topic所有分区都是有序的。

解决方案：

• 一个 topic，一个 partition，一个 consumer，内部单线程消费，单线程吞吐量太低；
• 生产者在发送消息的时候指定要发送到特定Partition，如此便可严格保证Kafka消息的顺序；

5、Kafka中的分区器、序列化器、拦截器是否了解？它们之间的处理顺序是什么？

• Kafka 一共有两种拦截器：生产者拦截器和消费者拦截器。
  • 生产者拦截器既可以用来在消息发送前做一些准备工作，比如按照某个规则过滤不符合要求的消息、修改消息的内容等，也可以用来在发送回调逻辑前做一些定制化的需求，比如统计类工作。
  • 消费者拦截器主要在消费到消息或在提交消费位移时进行一些定制化的操作。

• 序列化器：生产者需要用序列化器（Serializer）把对象转换成字节数组才能通过网络发送给 Kafka。而在对侧，消费者需要用反序列化器（Deserializer）把从 Kafka 中收到的字节数组转换成相应的对象。
• 分区器：分区器的作用就是为消息分配分区。如果消息 ProducerRecord 中没有指定 partition 字段，那么就需要依赖分区器，根据 key 这个字段来计算 partition 的值。

消息在通过 send() 方法发往 broker 的过程中，有可能需要经过拦截器（Interceptor）、序列化器（Serializer）和分区器（Partitioner）的一系列作用之后才能被真正地发往 broker。

处理顺序 ：拦截器->序列化器->分区器

6、Kafka生产者客户端的整体结构是什么样子的？

整个生产者客户端由两个线程协调运行，这两个线程分别为主线程和 Sender 线程。

• 主线程中由 KafkaProducer 创建消息，然后通过可能的拦截器、序列化器和分区器的作用之后缓存到消息累加器中。
• Sender 线程负责从 RecordAccumulator 中获取消息并将其发送到 Kafka 中。

RecordAccumulator 主要用来缓存消息以便 Sender 线程可以批量发送，进而减少网络传输的资源消耗以提升性能。

7、消费者提交消费位移时提交的是当前消费到的最新消息的offset还是offset+1?

• 在旧消费者客户端中，消费位移是存储在 ZooKeeper 中的。
• 在新消费者客户端中，消费位移存储在 Kafka 内部的主题__consumer_offsets 中。

当前消费者需要提交的消费位移是offset+1 。

8、有哪些情形会造成重复消费？

1. Rebalance：一个consumer正在消费一个分区的一条消息，还没有消费完，发生了rebalance，从而导致这条消息没有消费成功，rebalance后，另一个consumer又把这条消息消费一遍。
2. 消费者端手动提交：如果先消费消息，再更新offset位置，更新offset位置操作失败，导致消息重复消费。
3. 消费者端自动提交：设置offset为自动提交，关闭kafka时，如果在close之前，调用 consumer.unsubscribe()， 则有可能部分offset没提交，下次重启会重复消费。
4. 生产者端：生产者因为业务问题导致的宕机，在重启之后可能数据会重发。

9、那些情景下会造成消息漏消费？

1. 生产者发送消息：发送消息设置的是ACK==0，它只管往 Kafka 中发送消息而并不关心消息是否正确到达。不过在某些时候会造成消息的丢失。
2. 消费者端手动提交：先提交位移，但是消息还没消费完就宕机了，造成了消息没有被消费。
3. 消费者端自动提交：设置offset为自动定时提交，当offset被自动定时提交时，数据还在内存中未处理，此时刚好把线程kill掉，那么offset已经提交，但是数据未处理，导致这部分内存中的数据丢失。

10、KafkaConsumer是非线程安全的，那么怎么样实现多线程消费？

11、简述消费者与消费组之间的关系

1. Consumer Group 下可以有一个或多个 Consumer 实例。实例可以是一个单独的进程，也可以是同一进程下的线程。在实际场景中，使用进程更为常见一些。
2. Group ID 是一个字符串，在一个 Kafka 集群中，它标识唯一的一个 Consumer Group。
3. Consumer Group 下所有实例订阅的主题的单个分区，只能分配给组内的某个 Consumer 实例消费。这个分区当然也可以被其他的 Group 消费。

12、topic的分区数可不可以增加？如果可以怎么增加？如果不可以，那又是为什么？

可以增加，当分区数增加时，就会触发订阅该主题的所有 Group 开启 Rebalance。

1. 首先，Rebalance 过程对 Consumer Group 消费过程有极大的影响。在 Rebalance 过程中，所有 Consumer 实例都会停止消费，等待 Rebalance 完成。
2. 其次，目前 Rebalance 的设计是所有 Consumer 实例共同参与，全部重新分配所有分区。

更高效的做法是尽量减少分配方案的变动。

13、topic的分区数可不可以减少？如果可以怎么减少？如果不可以，那又是为什么？

不支持，因为删除的分区中的消息不好处理。

• 如果直接存储到现有分区的尾部，消息的时间戳就不会递增，如此对于 Spark、Flink 这类需要消息时间戳的组件将会受到影响；
• 如果分散插入现有的分区，那么在消息量很大的时候，内部的数据复制会占用很大的资源。
• 在复制期间，此主题的可用性无法得到保障。与此同时，顺序性问题、事务性问题，以及分区和副本的状态机切换问题都是不得不面对的。

14、Kafka目前有哪些内部topic，它们都有什么特征？各自的作用又是什么？

__consumer_offsets：作用是保存 Kafka 消费者的位移信息
__transaction_state：用来存储事务日志消息

15、简述Kafka的日志目录结构

Kafka 中的消息是以主题为基本单位进行归类的，各个主题在逻辑上相互独立。每个主题又可以分为一个或多个分区。一个分区对应一个日志（Log）。为了防止 Log 过大，Kafka 又引入了日志分段的概念，将 Log 切分为多个 LogSegment，相当于一个巨型文件被平均分配为多个相对较小的文件。

Log 在物理上只以文件夹的形式存储，而每个 LogSegment 对应于磁盘上的一个日志文件和两个索引文件，以及可能的其他文件。

16、聊一聊你对Kafka的Log Retention的理解

日志删除（Log Retention）：按照一定的保留策略直接删除不符合条件的日志分段。

1. 基于时间：检查当前日志文件中是否有保留时间超过设定的阈值，来寻找可删除的日志分段文件集合；
2. 基于日志大小：检查当前日志的大小是否超过设定的阈值，来寻找可删除的日志分段的文件集合；
3. 基于日志起始偏移量：判断依据是某日志分段的下一个日志分段的起始偏移量 baseOffset 是否小于等于 logStartOffset，若是，则可以删除此日志分段。

17、聊一聊你对Kafka的Log Compaction的理解

日志压缩（Log Compaction）：针对每个消息的 key 进行整合，对于有相同 key 的不同 value 值，只保留最后一个版本。如果应用只关心 key 对应的最新 value 值，则可以开启 Kafka 的日志清理功能，Kafka 会定期将相同 key 的消息进行合并，只保留最新的 value 值。

18、聊一聊你对Kafka底层存储的理解

零拷贝：除了消息顺序追加、页缓存等技术，Kafka 还使用零拷贝（Zero-Copy）技术来进一步提升性能。所谓的零拷贝是指将数据直接从磁盘文件复制到网卡设备中，而不需要经由应用程序之手。零拷贝大大提高了应用程序的性能，减少了内核和用户模式之间的上下文切换。

页缓存：页缓存是操作系统实现的一种主要的磁盘缓存，以此用来减少对磁盘 I/O 的操作。具体来说，就是把磁盘中的数据缓存到内存中，把对磁盘的访问变为对内存的访问。

当一个进程准备读取磁盘上的文件内容时，操作系统会先查看待读取的数据所在的页（page）是否在页缓存（pagecache）中，如果存在（命中）则直接返回数据，从而避免了对物理磁盘的 I/O 操作；如果没有命中，则操作系统会向磁盘发起读取请求并将读取的数据页存入页缓存，之后再将数据返回给进程。

同样，如果一个进程需要将数据写入磁盘，那么操作系统也会检测数据对应的页是否在页缓存中，如果不存在，则会先在页缓存中添加相应的页，最后将数据写入对应的页。被修改过后的页也就变成了脏页，操作系统会在合适的时间把脏页中的数据写入磁盘，以保持数据的一致性。

19、聊一聊Kafka的延时操作的原理

Kafka 中有多种延时操作，比如延时生产，还有延时拉取、延时数据删除等。

延时操作创建之后会被加入延时操作管理器来做专门的处理。延时操作有可能会超时，每个延时操作管理器都会配备一个定时器来做超时管理，定时器的底层就是采用时间轮实现的。

20、聊一聊Kafka控制器的作用

在 Kafka 集群中会有一个或多个 broker，其中有一个 broker 会被选举为控制器（Controller），它负责管理整个集群中所有分区和副本的状态。

当某个分区的 leader 副本出现故障时，由控制器负责为该分区选举新的 leader 副本。当检测到某个分区的 ISR 集合发生变化时，由控制器负责通知所有broker更新其元数据信息。当使用 kafka-topics.sh 脚本为某个 topic 增加分区数量时，同样还是由控制器负责分区的重新分配。

21、区分消费者leader、broker的Kafka Controller，消费者leader

Kafka Controller的功能
在Kafka集群中会有一个或多个broker，其中有一个broker会被选举为控制器（Kafka Controller），它负责管理整个集群中所有分区和副本的状态等工作。比如当某个分区的leader副本出现故障时，由控制器负责为该分区选举新的leader副本。再比如当检测到某个分区的ISR集合发生变化时，由控制器负责通知所有broker更新其元数据信息。

Kafka Controller的选举
Kafka Controller的选举是依赖Zookeeper来实现的，在Kafka集群中哪个broker能够成功创建/controller这个临时节点他就可以成为Kafka Controller。

分区leader的功能
分区leader主要用于对外提供服务

分区leader的选举
分区leader副本的选举由Kafka Controller 负责具体实施，具体思路为：从AR列表中找到第一个存活的副本，且这个副本在目前的ISR列表中，与此同时还要确保这个副本不处于正在被关闭的节点上。

消费者leader的选举
如果消费组内还没有leader，那么第一个加入消费组的消费者即为消费组的leader。如果某一时刻leader消费者由于某些原因退出了消费组，那么会重新选举一个新的leader，可以理解为随意从组内挑选一个消费者作为leader。

22、Kafka中的生产者幂等是怎么实现的？

幂等性的工作原理很简单，每条消息都有一个「主键」，这个主键由 <PID, Partition, SeqNumber> 组成，他们分别是：

• PID：ProducerID，每个生产者启动时，Kafka 都会给它分配一个 ID，ProducerID 是生产者的唯一标识，需要注意的是，Kafka 重启也会重新分配 PID
• Partition：消息需要发往的分区号
• SeqNumber：生产者，他会记录自己所发送的消息，给他们分配一个自增的 ID，这个 ID 就是 SeqNumber，是该消息的唯一标识

对于主键相同的数据，Kafka 是不会重复持久化的，它只会接收一条，但由于是原理的限制，幂等性也只能保证单分区、单会话内的数据不重复，如果 Kafka 挂掉，重新给生产者分配了 PID，还是有可能产生重复的数据，这就需要另一个特性来保证了——Kafka 事务。

23、Kafka中的消费者幂等是怎么实现的？

消费者手动提交偏移量+幂等性处理

首先解决数据丢失问题，手工来控制偏移量的提交时机，等数据保存成功后再提交偏移量。
把数据的保存做成幂等性保存。即同一批数据反复保存多次，数据不会翻倍，保存一次和保 存一百次的效果是一样的。

消费者的幂等性的保证完全可以根据业务需求进行具体分析。

24、Kafka中的事务是怎么实现的？

1）启动生产者，分配协调器
我们在使用事务的时候，必须给生产者指定一个事务 ID，生产者启动时，Kafka 会根据事务 ID 来分配一个事务协调器（Transaction Coordinator） 。每个 Broker 都有一个事务协调器，负责分配 PID和管理事务。

事务协调器的分配涉及到一个特殊的主题 __transaction_state，该主题默认有50个分区，每个分区负责一部分事务；Kafka 根据事务ID的hashcode值%50 计算出该事务属于哪个分区， 该分区 Leader 所在 Broker 的事务协调器就会被分配给该生产者。

分配完事务协调器后，该事务协调器会给生产者分配一个 PID，接下来生产者就可以准备发送消息了。

2）发送消息
生产者分配到 PID 后，要先告诉事务协调器要把消息发往哪些分区，协调器会做一个记录，然后生产者就可以开始发送消息了，这些消息与普通的消息不同，它们带着一个字段标识自己是事务消息。

当生产者事务内的消息发送完毕，会向事务协调器发送 Commit 或 Abort 请求，此时生产者的工作已经做完了，它只需要等待 Kafka 的响应。

3）确认事务
当生产者开始发送消息时，协调器判定事务开始，开始将消息持久化到主题transaction_state 中。

当生产者发送完事务内的消息，协调器会收到 Commit 或 Abort 请求，接着事务协调器会跟所有主题通信，告诉它们事务是成功还是失败的。

如果是成功，主题会汇报自己已经收到消息，协调者收到所有主题的回应便确认了事务完成，并持久化这一结果。

如果是失败的，主题会把这个事务内的消息丢弃，并汇报给协调者，协调者收到所有结果后再持久化这一信息，事务结束；整个放弃事务的过程消费者是无感知的，它并不会收到这些数据。

25、失效副本是指什么？有那些应对措施？

正常情况下，分区的所有副本都处于 ISR 集合中，但是难免会有异常情况发生，从而某些副本被剥离出 ISR 集合中。在 ISR 集合之外，也就是处于同步失效或功能失效的副本统称为失效副本，失效副本对应的分区也就称为同步失效分区。

26、多副本下，各个副本中的HW和LEO的演变过程

某个分区有3个副本分别位于 broker0、broker1 和 broker2 节点中，假设 broker0 上的副本1为当前分区的 leader 副本，那么副本2和副本3就是 follower 副本，整个消息追加的过程可以概括如下：

1. 生产者客户端发送消息至 leader 副本（副本1）中。
2. 消息被追加到 leader 副本的本地日志，并且会更新日志的偏移量。
3. follower 副本（副本2和副本3）向 leader 副本请求同步数据。
4. leader 副本所在的服务器读取本地日志，并更新对应拉取的 follower 副本的信息。
5. leader 副本所在的服务器将拉取结果返回给 follower 副本。
6. follower 副本收到 leader 副本返回的拉取结果，将消息追加到本地日志中，并更新日志的偏移量信息。

27、Kafka在可靠性方面做了哪些改进？

对于可靠性的保障，主要需要从生产者、Broker和消费者三个角度来进行实现。

保证生产者的消息可靠性
Kafka使用ack==-1 可以设置Broker收到消息并同步到所有从节点后给生产者一个确认消息。如果生产者没有收到确认消息就会多次重复向Broker发送消息，保证在生产者与Broker之间的消息可靠性。

保证Broker的消息可靠性
Kafka一般可被分成多个Broker节点，而为了增加Kafka的吞吐量，一个topic通常被分为多个partition，每个partition分布在不同的Broker上。如果一个partition丢失就会导致topic内容的部分丢失，因此partition往往需要多个副本，以此来保证高可用。这里还是需要强调一下，一定要将leader上的数据同步到follower上才能给生产者返回消息，否则可能造成消息丢失。

保证消费者的消息可靠性
比较容易发生消息丢失的情况是，消费者从Broker把消息拉过来，如果这个时候还没有消费完，消费者就挂了并且消费者自动提交了offset，那么此时就丢失了一条消息。所以解决办法就是关闭自动提交offset，等真正消费成功之后再手动提交offset。

28、为什么Kafka不支持读写分离？

因为这样有两个明显的缺点：

1. 数据一致性问题。数据从主节点转到从节点必然会有一个延时的时间窗口，这个时间窗口会导致主从节点之间的数据不一致。
2. 延时问题。数据从写入主节点到同步至从节点中的过程需要经历网络→主节点内存→主节点磁盘→网络→从节点内存→从节点磁盘这几个阶段。对延时敏感的应用而言，主写从读的功能并不太适用。

对于Kafka来说，必要性不是很高，因为在Kafka集群中，如果存在多个副本，经过合理的配置，可以让leader副本均匀的分布在各个broker上面，使每个 broker 上的读写负载都是一样的。

29、Kafka中的延迟队列怎么实现？

在发送延时消息的时候并不是先投递到要发送的真实主题（real_topic）中，而是先投递到一些 Kafka 内部的主题（delay_topic）中，这些内部主题对用户不可见，然后通过一个自定义的服务拉取这些内部主题中的消息，并将满足条件的消息再投递到要发送的真实的主题中，消费者所订阅的还是真实的主题。

发送到delay_topic中的消息会被一个独立的 DelayService 进程消费，这个 DelayService 进程和 Kafka broker 进程以一对一的配比进行同机部署（参考下图），以保证服务的可用性。

30、Kafka中怎么实现死信队列和重试队列？

死信可以看作消费者不能处理收到的消息，也可以看作消费者不想处理收到的消息，还可以看作不符合处理要求的消息。

• 消息内包含的消息内容无法被消费者解析，为了确保消息的可靠性而不被随意丢弃，故将其投递到死信队列中，此时可以将死信看作消费者不能处理的消息。
• 超过既定的重试次数之后将消息投入死信队列，此时可以将死信看作不符合处理要求的消息。

重试队列其实可以看作一种回退队列，具体指消费端消费消息失败时，为了防止消息无故丢失而重新将消息回滚到 broker 中。

重试队列一般分成多个重试等级，每个重试等级一般也会设置重新投递延时，重试次数越多投递延时就越大，并且需要设置一个上限，超过投递次数就进入死信队列。

31、Kafka中怎么做消息审计？

消息审计是指在消息生产、存储和消费的整个过程之间对消息个数及延迟的审计，以此来检测是否有数据丢失、是否有数据重复、端到端的延迟又是多少等内容。

对于每一条消息都会被分配一个全局唯一标识 ID。如果主题和相应的分区固定，则可以为每个分区设置一个全局的 ID。当有消息发送时，首先获取对应的 ID，然后内嵌到消息中，最后才将它发送到 broker 中。消费者进行消费审计时，可以判断出哪条消息丢失、哪条消息重复。

32、Kafka的那些设计让它有如此高的性能？

分区
kafka是个分布式集群的系统，整个系统可以包含多个broker，也就是多个服务器实例。每个主题topic会有多个分区，kafka将分区均匀地分配到整个集群中，当生产者向对应主题传递消息，消息通过负载均衡机制传递到不同的分区以减轻单个服务器实例的压力。

一个Consumer Group中可以有多个consumer，多个consumer可以同时消费不同分区的消息，大大的提高了消费者的并行消费能力。但是一个分区中的消息只能被一个Consumer Group中的一个consumer消费。

网络传输上减少开销
批量发送：在发送消息的时候，kafka不会直接将少量数据发送出去，否则每次发送少量的数据会增加网络传输频率，降低网络传输效率。kafka会先将消息缓存在内存中，当超过一个的大小或者超过一定的时间，那么会将这些消息进行批量发送。
端到端压缩：当然网络传输时数据量小也可以减小网络负载，kafaka会将这些批量的数据进行压缩，将一批消息打包后进行压缩，发送broker服务器后，最终这些数据还是提供给消费者用，所以数据在服务器上还是保持压缩状态，不会进行解压，而且频繁的压缩和解压也会降低性能，最终还是以压缩的方式传递到消费者的手上。

顺序读写
kafka将消息追加到日志文件中，利用了磁盘的顺序读写，来提高读写效率。

零拷贝技术
零拷贝将文件内容从磁盘通过DMA引擎复制到内核缓冲区，而且没有把数据复制到socket缓冲区，只是将数据位置和长度信息的描述符复制到了socket缓存区，然后直接将数据传输到网络接口，最后发送。这样大大减小了拷贝的次数，提高了效率。kafka正是调用linux系统给出的sendfile系统调用来使用零拷贝。

优秀的文件存储机制
如果分区规则设置得合理，那么所有的消息可以均匀地分布到不同的分区中，这样就可以实现水平扩展。不考虑多副本的情况，一个分区对应一个日志（Log）。为了防止 Log 过大，Kafka 又引入了日志分段（LogSegment）的概念，将 Log 切分为多个 LogSegment，相当于一个巨型文件被平均分配为多个相对较小的文件，这样也便于消息的维护和清理。

Kafka 中的索引文件以稀疏索引的方式构造消息的索引，它并不保证每个消息在索引文件中都有对应的索引项。每当写入一定量的消息时，偏移量索引文件和时间戳索引文件分别增加一个偏移量索引项和时间戳索引项，增大或减小 log.index.interval.bytes 的值，对应地可以增加或缩小索引项的密度。

33、Kafka 分区的目的？

• 分区对于 Kafka 集群的好处是：实现负载均衡。
• 分区对于消费者来说，可以提高并发度，提高效率。

34、Kafka 是如何实现高吞吐率的？

Kafka是分布式消息系统，需要处理海量的消息，Kafka的设计是把所有的消息都写入速度低容量大的硬盘，以此来换取更强的存储能力，但实际上，使用硬盘并没有带来过多的性能损失。kafka主要使用了以下几个方式实现了超高的吞吐率：

•顺序读写
•零拷贝
•文件分段
•批量发送
•数据压缩

35、Kafka 消息是采用 Pull 模式，还是 Push 模式？

Kafka 遵循了一种大部分消息系统共同的传统的设计：producer 将消息推送到 broker，consumer 从 broker 拉取消息

在push 模式下，当 broker 推送的速率远大于 consumer 消费的速率时，consumer 恐怕就要崩溃了。最终 Kafka 还是选取了传统的 pull 模式。

Pull 有个缺点是，如果 broker 没有可供消费的消息，将导致 consumer 不断在循环中轮询，直到新消息到 达。为了避免这点，Kafka 有个参数可以让 consumer 阻塞直到新消息到达。

36、Kafka 新建的分区会在哪个目录下创建

如果 log.dirs 参数配置了多个目录，那么 Kafka 会在哪个文件夹中创建分区目录呢？

答案是：Kafka 会在含有分区目录最少的文件夹中创建新的分区目录，分区目录名为 Topic
名+分区 ID。注意，是分区文件夹总数最少的目录，而不是磁盘使用量最少的目录！也就
是说，如果你给 log.dirs 参数新增了一个新的磁盘，新的分区目录肯定是先在这个新的磁
盘上创建直到这个新的磁盘目录拥有的分区目录不是最少为止。

37、Kafka 如何做到支持百万级 TPS ？