kafka 副本集设置和理解

转载请注明出处：

　　最近在做集群高可用验证的时候，遇到了一个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中被控制器移除。

此处需要注意两个配置容易误解：

1. ReplicationFactor: 1 (副本因子：1)

   • 这是最重要的配置！它意味着Kafka只会为这个分区的数据创建1个副本。这是数据的冗余度，决定了容错能力。

   • 1 表示 “没有冗余”。就像只把文件打印了一份。

2. 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