转载请注明出处：
最近在做集群高可用验证的时候，遇到了一个kafka 副本集高可用的问题，在这里分析总结一下。
当前的部署情况是kafka集群有三个节点；在做集群高可用验证的时候，先shutdown一个服务器实例之后，再验证服务相关的高可用，当shutdown一个实例之后，发现kafka 有的topic可以正常发送和接收消息，而有的topic 却不能。
报错的关键日志：
org.apache.kafka.common.errors.TimeoutException: Expiring 53 record(s) for TWAMP_LINK_TOPIC-0: 120000 ms has passed since batch creation再经过层层排查之后，通过以下命令，找到了关键点。
kafka-run-class kafka.admin.TopicCommand --describe --topic TUNNEL_STATE_TOPIC --bootstrap-server kafka2:9092注意将 --topic 之后的topic 换成不同的topic进行查看，具体显示如下：
根据提供的两个Topic的描述信息，可以得出以下结论：
| 主题名 (Topic) | 状态 | 分区 | 副本因子 | Leader | 副本位置 | ISR | 诊断结果 |
|---|---|---|---|---|---|---|---|
| TWAMP_LINK_TOPIC | 严重故障 | 0 | 1 | none | 3 | 3 | 完全不可用。因唯一副本在Broker 3上，且Broker 3已宕机。 |
| TUNNEL_STATE_TOPIC | 脆弱但可用 | 0 | 1 | 1 | 1 | 1 | 当前可用，但处于高风险中。因唯一副本在Broker 1上。 |
再切换了之后，发现有的topic 存在正常的leader、 而有的topic 却不存在leader。 而kafka 发送消息是通过leader去发送的，没有leader就会异常。
输出结果详解：
第一行：Topic 级别的概要信息
Topic: TWAMP_LINK_TOPIC TopicId: iw-DWE9jSBKsxT7NJwQBzQ PartitionCount: 1 ReplicationFactor: 1 Configs:| 参数 | 值 | 解释 |
|---|---|---|
Topic: |
TWAMP_LINK_TOPIC |
Topic的名称，由用户或应用程序创建时指定。 |
TopicId: |
iw-DWE9jSBKsxT7NJwQBzQ |
Topic的唯一内部标识符。在Kafka集群内部，TopicId比Topic名称更常用，因为它不会因Topic重命名而改变。这是一个由Kafka自动生成的唯一字符串。 |
PartitionCount: |
1 |
该Topic的分区总数。分区是Kafka实现水平扩展和并行处理的基础单元。1表示所有数据都写入同一个分区，这可能会成为性能瓶颈。 |
ReplicationFactor: |
1 |
副本因子。这是当前最关键、最不健康的参数。它表示Topic的每个分区数据有多少个副本。1意味着数据没有冗余，只在集群中的一台Broker上存了一份。这是生产环境的反模式，没有任何容错能力。 |
Configs: |
(空) | 显示该Topic级别的自定义配置（会覆盖Broker的全局默认配置）。例如retention.ms（数据保留时间）、cleanup.policy（清理策略）等。这里是空的，表示全部使用集群默认配置。 |
第二行：分区级别的详细信息
Topic: TWAMP_LINK_TOPIC Partition: 0 Leader: none Replicas: 3 Isr: 3| 参数 | 值 | 解释 |
|---|---|---|
Topic: |
TWAMP_LINK_TOPIC |
分区所属的Topic名称。 |
Partition: |
0 |
分区编号。由于PartitionCount: 1，所以只有一个分区，编号从0开始。 |
Leader: |
none |
这是最直接的故障表现！ 表示这个分区的领导者副本。所有客户端的读写请求都必须发往Leader副本。 none 意味着当前没有可用的Leader。因为唯一的副本（在Broker 3上）已经宕机，导致无法进行读写操作，从而引发 TimeoutException。 |
Replicas: |
3 |
副本列表。列出了存放这个分区数据的所有Broker的ID。 重要：这里的 3 是Broker的编号，不是数量！ 它的含义是："这个分区的所有副本（因为ReplicationFactor: 1，所以其实就一个副本）存放在ID为3的Broker上。" 如果ReplicationFactor是3，这里可能会显示 Replicas: 1,2,3。 |
Isr: |
3 |
同步副本集（In-Sync Replicas）。这是一个动态列表，包含了当前所有与Leader副本保持同步的副本所在的Broker ID。 在健康状态下，Isr 列表应该和 Replicas 列表一致（例如 Replicas: 1,2,3 和 Isr: 1,2,3）。 这里的 3 表示：同步副本集中唯一的成员是Broker 3。 但因为Broker 3宕机了，这个信息是"最后已知的良好状态"，实际上它已经不同步了，很快就会从ISR中被控制器移除。 |
此处需要注意两个配置容易误解：
-
ReplicationFactor: 1(副本因子：1)-
这是最重要的配置！它意味着Kafka只会为这个分区的数据创建1个副本。这是数据的冗余度，决定了容错能力。
-
1表示 "没有冗余"。就像只把文件打印了一份。
-
-
Replicas: 3(副本所在Broker ID：3)-
这个字段只是告诉你：那唯一的一个副本，被放置在了Broker ID 为 3 的服务器上。
-
它不是说有三个副本。这里的
3是一个Broker编号，不是数量。 -
如果把
Replicas: 3换成Replicas: 1，意思就是那唯一的一个副本在Broker 1上。
-
解决方法：
重新创建topic，并设置topic的副本因子的数量大于1；从而保证高可用
kafka-topics.sh --create --topic TWAMP_LINK_TOPIC \
--partitions 1 \
--replication-factor 3 \ # 关键！必须设置为 3，为每个分区创建3个副本
--bootstrap-server kafka1:9092