kafka 副本集设置和理解

转载请注明出处：
　　最近在做集群高可用验证的时候，遇到了一个kafka 副本集高可用的问题，在这里分析总结一下。
　　当前的部署情况是kafka集群有三个节点；在做集群高可用验证的时候，先shutdown一个服务器实例之后，再验证服务相关的高可用，当shutdown一个实例之后，发现kafka 有的topic可以正常发送和接收消息，而有的topic 却不能。
　　报错的关键日志：

1. org.apache.kafka.common.errors.TimeoutException: Expiring 53 record(s) for TWAMP_LINK_TOPIC-0: 120000 ms has passed since batch creation

复制代码

　　再经过层层排查之后，通过以下命令，找到了关键点。

1. 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严重故障01none33完全不可用。因唯一副本在Broker 3上，且Broker 3已宕机。TUNNEL_STATE_TOPIC脆弱但可用01111当前可用，但处于高风险中。因唯一副本在Broker 1上。再切换了之后，发现有的topic 存在正常的leader、 而有的topic 却不存在leader。 而kafka 发送消息是通过leader去发送的，没有leader就会异常。
输出结果详解：
第一行：Topic 级别的概要信息

1. Topic: TWAMP_LINK_TOPIC TopicId: iw-DWE9jSBKsxT7NJwQBzQ PartitionCount: 1 ReplicationFactor: 1 Configs:

复制代码

参数值解释Topic:TWAMP_LINK_TOPICTopic的名称，由用户或应用程序创建时指定。TopicId:iw-DWE9jSBKsxT7NJwQBzQTopic的唯一内部标识符。在Kafka集群内部，TopicId比Topic名称更常用，因为它不会因Topic重命名而改变。这是一个由Kafka自动生成的唯一字符串。PartitionCount:1该Topic的分区总数。分区是Kafka实现水平扩展和并行处理的基础单元。1表示所有数据都写入同一个分区，这可能会成为性能瓶颈。ReplicationFactor:1副本因子。这是当前最关键、最不健康的参数。它表示Topic的每个分区数据有多少个副本。1意味着数据没有冗余，只在集群中的一台Broker上存了一份。这是生产环境的反模式，没有任何容错能力。Configs:(空)显示该Topic级别的自定义配置（会覆盖Broker的全局默认配置）。例如retention.ms（数据保留时间）、cleanup.policy（清理策略）等。这里是空的，表示全部使用集群默认配置。第二行：分区级别的详细信息

1. 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；从而保证高可用

1. kafka-topics.sh --create --topic TWAMP_LINK_TOPIC \
2. --partitions 1 \
3. --replication-factor 3 \  # 关键！必须设置为 3，为每个分区创建3个副本
4. --bootstrap-server kafka1:9092

复制代码

 

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！