目录
十四、Kafka 中 Leader 挂了，Follower 挂了，然后再启动，数据同步
十五、kafka中初始化的时候Leader选举有一定的规律，如何打破这个规律呢？
Kafka 作为一款广泛应用于大数据领域的分布式消息系统，其复杂的架构与机制蕴含着众多值得深入探究的知识要点。本文旨在全面剖析 Kafka 的核心概念与关键操作，包括消息发送流程、设计架构、分区目的、副本管理（如 ISR、OSR、AR 概念及其相互关系）、消息有序性保证、可靠性保障、数据去重、生产者吞吐量提升方法、Zookeeper 在集群中的作用、集群中的 Leader 选举机制、数据乱序处理、节点的服役与退役以及特殊情况下的数据同步与 Leader 选举规律打破等内容。通过对这些要点的详细阐述，无论是准备 Kafka 相关面试，还是致力于在实际项目中深入运用 Kafka 技术构建高效可靠的分布式系统，读者都能够从中获取系统且实用的知识，为深入理解和熟练掌握 Kafka 奠定坚实基础。
一、Kafka 消息发送流程
在消息发送的过程中，涉及到了两个线程——main 线程和 Sender 线程。在 main 线程中创建了一个双端队列 RecordAccumulator。main 线程将消息发送给 RecordAccumulator，Sender 线程不断从 RecordAccumulator 中拉取消息发送到 Kafka Broker。
Kafka消息发送的基本流程可以分为以下几个步骤：
1. 生产者创建: 生产者（Producer）是负责生成消息的应用程序组件。首先需要通过`KafkaProducer`类创建一个实例，并配置相关的参数，如指定主题（Topic）。
2. 消息缓存: 生产者通常会将消息暂存在内存中的批次（Batch）或分区（Partition）中，等待达到预设大小或时间间隔后再发送。
3. 发送请求: 当批次准备好后，生产者会将消息发送到相应的主题。每个主题由多个分区组成，所以可以选择特定分区进行发送，也可以让Kafka自动选择。
4. 确认与同步: 发送完成后，生产者通常会等待服务器的响应确认，这有助于保证数据的一致性和完整性。可以设置异步模式，生产者无需等待确认，适合高吞吐场景；也可以设置同步模式，等待服务器确认后再继续。
5. 事务处理: 如果支持，生产者还可以提交或回滚事务，这对于确保数据在发送过程中的原子性非常重要。
6. 错误处理: 如果网络中断或其他原因导致消息无法发送，生产者会记录错误并可能重试。
二、Kafka 的设计架构
Kafka 主要由多个 producer（生产者）、broker（代理节点）、consumer（消费者）以及 zookeeper 等组成。生产者负责生产消息并发送到 broker。broker 是 Kafka 集群的核心，存储消息并处理生产者和消费者的请求，一个 broker 可以包含多个 topic（主题），每个 topic 又可分为多个 partition（分区）。消费者从 broker 订阅主题并消费消息。Zookeeper 用于管理 Kafka 集群的元数据信息，例如 broker 节点的注册与发现、topic 配置信息、consumer 消费位移信息等，协调 Kafka 集群的各项操作，如 leader 选举等。
1）Producer：消息生产者，就是向 Kafka broker 发消息的客户端。
2）Consumer：消息消费者，向 Kafka broker 取消息的客户端。
3）Consumer Group（CG）：消费者组，由多个 consumer 组成。消费者组内每个消 费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
4）Broker：一台 Kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic。
5）Topic：可以理解为一个队列，生产者和消费者面向的都是一个 topic。
6）Partition：为了实现扩展性，一个非常大的 topic 可以分布到多个 broker（即服务器）上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列。
7）Replica：副本。一个 topic 的每个分区都有若干个副本，一个 Leader 和若干个 Follower。
8）Leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 Leader。
9）Follower：每个分区多个副本中的“从”，实时从 Leader 中同步数据，保持和 Leader 数据的同步。Leader 发生故障时，某个 Follower 会成为新的 Leader。
三、Kafka 分区的目的
- 提高并行度：生产者可以以分区为单位发送数据；消费者可以以分区为单位进行消费数据。
- 便于数据存储与管理：每个Partition在一个Broker上存储，可以把海量的数据按照分区切割成一块一块数据存储在多台Broker上。合理控制分区的任务，可以实现负载均衡的效果。
四、Kafka 保证消息有序性的方式
1、消息分区
kafka将数据分散存储在多个broker节点上。每个主题(topic)可以被划分成多个不同的分区(partition)，而且每个分区内的消息都有自己的offset偏移量。这个offset可以看作是一条消息在分区中的唯一标识符，kafka会确保每个分区内部的消息存储顺序是有序的。
2、生产者端有序性
在kafka中，生产者(producer)可以选择将消息发送到指定的分区，也可以让kafka自动为消息选择一个合适的目标分区。当生产者使用同步发送(sync)方式将消息发送到指定的分区时，kafka会按照消息发送的顺序依次将它们写入到目标分区中。
3、消费者端有序性
消费者(consumer)从kafka中读取消息时，可以指定读取的起始位置(offset)，kafka会按照offset顺序返回消息给客户端。在消费者组消费场景下，kafka还会对多个消费者之间的消息进行协调，确保每条消息只能被其中一个消费者处理，并且每个消费者只能读取到特定分区内的消息，这样就保证了消费者端的有序性。
五、ISR、OSR、AR 概念
AR（Assigned Replicas）
AR（Assigned Replicas）：AR 是指分配给某个分区的所有副本集合。每个分区都有一个 AR 集合，包含了该分区的所有副本，包括主副本（Leader）和从副本（Follower）。
功能：
- 副本分配：AR 集合定义了分区的副本分布情况。Kafka 使用副本分配策略将分区的副本分布在不同的 Broker 上，以实现负载均衡和高可用性。
- 副本管理：AR 集合是副本管理的基础。Kafka 通过 AR 集合来跟踪和管理分区的所有副本，包括副本的创建、删除、同步和故障恢复。
ISR（In-Sync Replicas）
ISR（In-Sync Replicas）：ISR 是指与主副本保持同步的副本集合。ISR 集合包含了所有与主副本数据一致的副本，包括主副本本身和同步的从副本。
功能：
- 数据一致性：ISR 集合确保了数据的一致性。只有 ISR 中的副本才能参与领导选举和数据恢复，确保数据的一致性和可靠性。
- 故障恢复：ISR 集合是故障恢复的关键。当主副本发生故障时，Kafka 从 ISR 集合中选择一个新的主副本，确保分区的连续运行和数据的一致性。
同步机制：
- 同步条件：从副本必须满足一定的同步条件才能进入 ISR 集合。通常，从副本需要与主副本保持一定的同步进度，如在一定时间内完成数据同步，才能被认为是同步的。
- 同步监控：Kafka 定期监控从副本的同步状态，将满足同步条件的从副本加入 ISR 集合，将不同步的从副本移出 ISR 集合。
OSR（Out-of-Sync Replicas）
OSR（Out-of-Sync Replicas）：OSR 是指与主副本不同步的副本集合。OSR 集合包含了所有未满足同步条件的从副本。
功能：
- 副本同步监控：OSR 集合用于监控副本的同步状态。Kafka 通过 OSR 集合来识别不同步的副本，并采取相应的同步措施，如重新同步数据，以确保副本的同步状态。
- 故障恢复：OSR 集合在故障恢复中起到辅助作用。当主副本发生故障时，Kafka 优先从 ISR 集合中选择新的主副本，但如果 ISR 集合为空，Kafka 可能会从 OSR 集合中选择一个副本作为新的主副本。
AR、ISR、OSR 的关系和交互
AR 包含 ISR 和 OSR：AR 集合包含了分区的所有副本，包括 ISR 和 OSR。ISR 集合是 AR 集合的子集，包含了所有同步的副本。OSR 集合是 AR 集合的子集，包含了所有不同步的副本。
- 同步监控：Kafka 定期监控从副本的同步状态，将同步的副本加入 ISR 集合，将不同步的副本移入 OSR 集合。
- 故障恢复：当主副本发生故障时，Kafka 从 ISR 集合中选择一个新的主副本，确保分区的连续运行和数据的一致性。如果 ISR 集合为空，Kafka 可能会从 OSR 集合中选择一个副本作为新的主副本。
- 副本分配：Kafka 使用 AR 集合来管理分区的副本分配，确保副本的均衡分布和高可用性。
- 副本同步：Kafka 使用 ISR 和 OSR 集合来监控和管理副本的同步状态，确保数据的一致性和可靠性。
Kafka 中的 AR、ISR 和 OSR 是副本管理的核心概念，它们共同构成了 Kafka 副本同步和故障恢复的机制。AR 集合定义了分区的副本分布情况，ISR 集合确保了数据的一致性和可靠性，OSR 集合监控和管理不同步的副本。通过合理配置和管理这些机制，Kafka 能够构建高效、可靠的分布式消息系统，满足各种复杂场景下的数据安全需求
六、Kafka 在什么情况下会出现消息丢失
Kafka在以下情况下可能会出现数据丢失:
1.消息生产端未设置acks参数或设置为0，导致生产者不等待broker的确认消息就继续发送下一条消息，这样就有可能造成数据丢失,。2.消息生产端设置acks参数为1、但是broker在接收到消息后还未来得及将消息写入磁盘就宕机了，这样也会导致数据丢失
3.消息消费端手动提交偏移量时，偏移量提交失败或者提交了错误的偏移量，就可能会造成数据重复消费或者消息丢失。
4. Kafka集群中某些broker宕机或者网络故障等原因导致消息丢失。
为了避免数据丢失，可以采取以下措施:
1.生产者设置acks参数为1或者all，确保消息被成功写入broker的所有副本后再返回确认消息。
2.消费者使用自动提交偏移量的方式，避免手动提交偏移量时出现的问题,
3.使用Kafka的复制机制，保证数据的高可用性，防止因为某个broker宕机导致消息丢失4.定期备份和监控Kafka集群，确保及时发现和解决可能存在的问题，
七、保证 Kafka 可靠性的方法
数据完全可靠条件 = ACK级别设置为-1 + 分区副本大于等于2 + ISR里应答的最小副本数量大于等于2
acks=0
生产者发送过来数据就立马回送ack,不管消息是否成功，消息是否在broker处落盘成功
可靠性差，效率高
acks=1
生产者发送过来数据Leader应答，如果leader刚回送ack,但是leader挂了，follow没办法进行同步
可靠性中等，效率中等
acks=-1（all）
生产者发送过来数据Leader和ISR队列里面所有Follwer应答，这种情况下仍然会丢数，因为如果isr只有leader的时候，这个时候就和ack=1一样
可靠性高，效率低
在生产环境中，acks=0很少使用；acks=1，一般用于传输普通日志，允许丢个别数据；
acks=-1，一般用于传输和钱相关的数据，对可靠性要求比较高的场景。
八、Kafka 数据去重
至少一次（At Least Once）= ACK级别设置为-1 + 分区副本大于等于2 + ISR里应答的最小副本数量大于等于2 可以保障数据可靠
• 最多一次（At Most Once）= ACK级别设置为0
• 总结：
At Least Once可以保证数据不丢失，但是不能保证数据不重复；
At Most Once可以保证数据不重复，但是不能保证数据不丢失。
• 精确一次（Exactly Once）：对于一些非常重要的信息，比如和钱相关的数据，要求数据既不能重复也不丢失。 --幂等性和事务可以保障数据精确一次
Kafka 0.11版本以后，引入了一项重大特性：幂等性和事务。
幂等性原理
幂等性就是指Producer不论向Broker发送多少次重复数据，Broker端都只会持久化一条，保证了不重复。
精确一次（Exactly Once） = 幂等性 + 至少一次（ ack=-1 + 分区副本数>=2 + ISR最小副本数量>=2） 。
幂等性有点类似于sql语句中的 distinct
重复数据的判断标准：具有 <PID, Partition, SeqNumber>相同主键的消息提交时，Broker只会持久化一条。其中PID是Kafka每次重启都会分配一个新的；Partition 表示分区号；Sequence Number是单调自增的。
所以幂等性只能保证的是在单分区单会话(重启会话就是下一次了)内不重复。
如果kafka集群挂了，重启了，此时以前的数据还会发送一回，数据又重复了。
九、生产者提高吞吐量的方法
- 增加 batch.size：批量发送消息可以减少网络请求次数，提高吞吐量。适当增大 batch.size 可以将更多消息一次性发送，但要注意不能设置过大导致内存占用过高或消息发送延迟增加。
- 调整 linger.ms：linger.ms 控制生产者在发送当前批次消息之前等待更多消息加入批次的时间。增大 linger.ms 可以让生产者等待更多消息累积后再发送，从而提高批量发送的效率，但也会增加消息发送的延迟。
- 设置 compression.type：对消息进行压缩可以减少网络传输的数据量，提高传输效率。可选择的压缩算法有 gzip、snappy、lz4 等，不同算法在压缩比和压缩 / 解压缩性能上有所差异，需要根据实际情况选择。
- 适当增大缓冲区大小：在 Kafka 生产者中，
RecordAccumulator是一个用于缓存待发送消息的缓冲区。通过适当增大RecordAccumulator的缓冲区大小，可以在一定程度上提高生产者的吞吐量 - 增加分区数量：更多的分区意味着可以并行处理更多的消息，提高整体的吞吐量。但分区数量也不是越多越好，过多的分区会增加管理成本和元数据开销，可能导致性能下降。
- 优化硬件资源：使用更快的 CPU、更大的内存、更高带宽的网络等硬件资源，可以直接提升生产者的性能，从而提高吞吐量。
十、Zookeeper 在 Kafka 集群中的作用
- 协调和领导者选举：Zookeeper协助Kafka集群中的各个Broker选举一个领导者（Leader）。这个领导者负责管理分区的写入和读取请求，并协调分布式的事务。如果领导者发生故障，Zookeeper会帮助选举一个新的领导者。
- 分区分配：当新的消费者加入或现有消费者离开Kafka集群时，Zookeeper协助进行分区分配，确保每个消费者获得它们要订阅的分区。
- 配置管理：Kafka的一些配置参数和元数据信息（如分区和副本的状态）也存储在Zookeeper中，以供Kafka集群中的各个Broker和消费者使用。
十一、Kafka 集群中的 Leader 选举机制
kafka集群中有一个broker的controller会被选举为controller Leader，负责管理集群broker的上下线，所有topic的分区副本分配和Leader选举等工作。
controller的信息同步工作依赖于zookeeper。
1.broker启动后在zk中注册
2.controller谁先注册，就听谁的
3.由选举出来的controller监听broker节点变化
4.controller决定了Leader选举
选举规则：在isr中存活为前提，按照AR中排在前面的优先。例如：ar[1,0,2],isr[1,0,2]，Leader就会按照1,0,2的顺序轮询。
5.controller将节点信息上传到zk
6.其他controller从zk中同步相关信息
7.当broker中的Leader挂了
8.controller监听到了节点变化
9.获取isr
10.选举新的Leader（在isr中存活为前提，按照ar中排在最前面的优先）
11.更新Leader和isr。
十二、Kafka 处理数据乱序问题
1）kafka在1.x版本之前保证数据单分区有序，条件如下:
max.in.flight.requests.per.connection=1（不需要考虑是否开启幂等性）
2)kafka在1.x及以后版本保证数据单分区有序，条件如下：
1.开启幂等性
max.in.flight.requests.per.connection需要设置小于等于5。
2.未开启幂等性
max.in.flight.requests.per.connection需要设置为1。
原因：因为在kafka1.x之后，启用幂等性后，kafka服务端会缓存producer发来的最近5个request的元数据，所以无论如何都会保证最近5个request的数据是有序的。
出现乱序的原因
生产者在发送3请求时，发生异常，发生异常需要重新发送，所以排在了后面，在进行落盘的时候，先落盘1,2，落盘3的时候发现是4，此时会等到3出现为止，然后将345排序，排序后再进行后续落盘。
顺序错乱了，会自动排序（开启幂等性）。
十三、Kafka 中节点的服役和退役
假设集群只有hadoop102、hadoop103、hadoop104中有kafka的节点，现在需要在hadoop105中新增一个节点，并且需要将部分主题的数据迁移到新增的节点中。或者将hadoop105节点退役掉，需要将105中的主题的数据迁移到现役的broker中。
服役新节点
在hadoop105上安装kafka，启动hadoop102、hadoop103、hadoop104上的kafka集群，修改haodoop105中kafka的broker.id为3，单独启动hadoop105中的kafka
bin/kafka-server-start.sh -daemon ./config/server.properties在kafka下创建一个要均衡的主题
创建一个文件：vi topics-to-move.json
写上如下代码，如果多个topic 可以使用,分隔
{
"topics": [
{"topic": "third"}
],
"version": 1
}生成一个负载均衡的计划
bin/kafka-reassign-partitions.sh --bootstrap-server bigdata01:9092 --topics-to-move-json-file topics-to-move.json --broker-list "0,1,2,3" --generate
分区策略拷贝一份
{"version":1,"partitions":[{"topic":"abc","partition":0,"replicas":[2,0,1],"log_dirs":["any","any","any"]},{"topic":"abc","partition":1,"replicas":[3,1,2],"log_dirs":["any","any","any"]},{"topic":"abc","partition":2,"replicas":[0,2,3],"log_dirs":["any","any","any"]}]}创建副本存储计划（所有副本存储在broker0、broker1、broker2、broker3中）。
vim increase-replication-factor.json将上方系统生成的Proposed partition reassignment configuration下的内容复制到 increase-replication-factor.json
{"version":1,"partitions":[{"topic":"first","partition":0,"replicas":[3,2,0],"log_dirs":["any","any","any"]},{"topic":"first","partition":1,"replicas":[0,3,1],"log_dirs":["any","any","any"]},{"topic":"first","partition":2,"replicas":[1,0,2],"log_dirs":["any","any","any"]}]}执行副本存储计划
bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092 --reassignment-json-file increase-replication-factor.json --execute验证副本存储计划(可以通过命令的形式查看或者去105节点上查看)
[wyp@hadoop102 kafka]$ bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092 --reassignment-json-file increase-replication-factor.json --verify
执行后看到如下输出就是完成节点的数据均衡了。
Status of partition reassignment:
Reassignment of partition first-0 is complete.
Reassignment of partition first-1 is complete.
Reassignment of partition first-2 is complete.
Clearing broker-level throttles on brokers 0,1,2,3
Clearing topic-level throttles on topic first
退役旧节点
创建一个要均衡的主题
kafka下添加文件：vim topics-to-move.json
添加如下内容：
{
"topics": [
{"topic": "abc"}
],
"version": 1
}创建执行计划
[wyp@hadoop102 kafka]$ bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092 --topics-to-move-json-file topics-to-move.json --broker-list "0,1,2" --generate
Current partition replica assignment
{"version":1,"partitions":[{"topic":"first","partition":0,"replicas":[2,0,1],"log_dirs":["any","any","any"]},{"topic":"first","partition":1,"replicas":[3,1,2],"log_dirs":["any","any","any"]},{"topic":"first","partition":2,"replicas":[0,2,3],"log_dirs":["any","any","any"]}]}
Proposed partition reassignment configuration
{"version":1,"partitions":[{"topic":"first","partition":0,"replicas":[2,0,1],"log_dirs":["any","any","any"]},{"topic":"first","partition":1,"replicas":[0,1,2],"log_dirs":["any","any","any"]},{"topic":"first","partition":2,"replicas":[1,2,0],"log_dirs":["any","any","any"]}]}
创建副本存储计划
[wyp@hadoop102 kafka]$ vim increase-replication-factor.json
# 把上方的Proposed partition reassignment configuration复制到文件中
{"version":1,"partitions":[{"topic":"first","partition":0,"replicas":[2,0,1],"log_dirs":["any","any","any"]},{"topic":"first","partition":1,"replicas":[0,1,2],"log_dirs":["any","any","any"]},{"topic":"first","partition":2,"replicas":[1,2,0],"log_dirs":["any","any","any"]}]}
执行副本存储计划
[wyp@hadoop102 kafka]$ bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092 --reassignment-json-file increase-replication-factor.json --execute
验证副本存储计划
[wyp@hadoop102 kafka]$ bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092 --reassignment-json-file increase-replication-factor.json --verify
Status of partition reassignment:
Reassignment of partition first-0 is complete.
Reassignment of partition first-1 is complete.
Reassignment of partition first-2 is complete.
Clearing broker-level throttles on brokers 0,1,2,3
Clearing topic-level throttles on topic first
总结
kafka节点的服役和退役的节点操作是相同，均是将主题中的数据均匀的分配到新增或者删除节点之外的borker中。
操作步骤：
(1)创建需要均衡的主题；
(2)生成负载均衡的计划；
(3)创建并执行生成的负载均衡的计划；
(4)验证计划的执行情况。
需要注意的是，服役节点时，新增的节点的brokerId需要修改，rsync复制过去的需要将data、logs中的内容删除掉。
十四、Kafka 中 Leader 挂了，Follower 挂了，然后再启动，数据同步
由于数据同步的时候先进入Leader,随后同步给Follower，假如Follower挂掉了，Leader和其他的Follower 继续往前存储数据，挂掉的节点从ISR集合中剔除，此时挂掉的Follower又重启了，它会先从上一次挂掉的节点的HW开始同步数据，直到追上最后一个Follower为止,此时会重新回归ISR。
Follower 恢复启动：当 Follower 节点重新启动后，它会向 Controller 发送请求，获取自己所属分区的 leader 信息以及 ISR 集合信息。然后，Follower 会根据这些信息与 leader 建立连接，并从 leader 副本拉取自己落后的数据进行同步。在同步过程中，Follower 会不断向 leader 发送 FetchRequest 请求，获取消息数据，并将其写入本地日志文件，直到与 leader 的数据差距缩小到 ISR 所允许的范围内，此时该 Follower 会重新加入 ISR 集合，完成数据同步过程。
Leader 恢复启动：如果 Leader 节点重新启动，它首先会检查本地的日志数据是否完整。如果数据完整，它会向 Controller 注册自己，并等待 Controller 协调其他副本与它进行数据同步（如果有需要）。Controller 会根据之前记录的元数据信息，通知其他 Follower 副本与新启动的 leader 进行同步操作，确保各个副本的数据一致性。如果 leader 节点发现本地数据不完整（例如在宕机前某些数据未持久化到磁盘），则可能需要根据具体情况进行数据恢复操作，如从其他副本或备份中获取缺失的数据，然后再进行同步操作，以保证整个分区的数据完整性和一致性。
十五、kafka中初始化的时候Leader选举有一定的规律，如何打破这个规律呢？
初始化 Leader 选举规律
在 Kafka 初始化创建 topic 时，对于每个分区的 leader 选举，通常是按照 broker 节点的编号顺序进行选择的。例如，如果有三个 broker 节点（broker.id 分别为 0、1、2），那么第一个分区的 leader 可能会选择 broker.id 为 0 的节点，第二个分区的 leader 可能会选择 broker.id 为 1 的节点，以此类推。这种选举规律是为了在初始化时能够快速、简单地确定 leader 副本，避免复杂的选举过程。
打破规律的方法：手动调整分区副本的存储
在生产环境中，每台服务器的配置和性能不一致，但是Kafka只会根据自己的代码规则创建对应的分区副本，就会导致个别服务器存储压力较大。所有需要手动调整分区副本的存储。
需求：创建一个新的topic，4个分区，两个副本，名称为three。将 该topic的所有副本都存储到broker0和broker1两台服务器上。
手动调整分区副本存储的步骤如下：
（1）创建一个新的 topic，名称为 three。
bin/kafka-topics.sh --bootstrap-server bigdata01:9092 --create --partitions 4 --replication-factor 2 --topic three （2）查看分区副本存储情况。
bin/kafka-topics.sh --bootstrap-server bigdata01:9092 --describe --topic three（3）创建副本存储计划（所有副本都指定存储在 broker0、broker1 中）。
vi increase-replication-factor.json 输入如下内容：
{
"version":1,
"partitions":[{"topic":"three","partition":0,"replicas":[0,1]},
{"topic":"three","partition":1,"replicas":[0,1]},
{"topic":"three","partition":2,"replicas":[1,0]},
{"topic":"three","partition":3,"replicas":[1,0]}]
}（4）执行副本存储计划。
bin/kafka-reassign-partitions.sh --bootstrap-server bigdata01:9092 --reassignment-json-file increase-replication-factor.json --execute（5）验证副本存储计划。
bin/kafka-reassign-partitions.sh -- bootstrap-server bigdata01:9092 --reassignment-json-file increase-replication-factor.json --verify（6）查看分区副本存储情况
bin/kafka-topics.sh --bootstrap-server bigdata01:9092 --describe --topic three
掌握这些 Kafka 的核心知识要点，无论是应对面试还是深入理解和应用 Kafka 技术，都将具有极大的帮助。希望本文能为大家在 Kafka 的学习和实践道路上提供有益的参考和指引。
标签：副本,分区,Kafka,topic,kafka,要点,解析,any From： https://blog.csdn.net/weixin_64726356/article/details/143641983