高可用架构

Kafka 高可用由 KRaft Controller Quorum、Broker、Partition Replica、ISR 和客户端重试共同组成。Controller 高可用负责元数据，Partition 副本高可用负责业务消息，两者不能混为一层。

高可用模块

模块	高可用职责	关键边界
Bootstrap Server	让客户端发现完整集群	不是固定代理层，客户端随后直连目标 Broker
KRaft Controller Quorum	维护元数据并选举 Active Controller	失去多数 Controller 会影响元数据变更和故障处理
Partition Replica	保存业务消息副本	复制因子决定副本总数，不直接等于可用写入数
ISR	限定可安全参与 Leader 选举和确认的同步副本	ISR 收缩表示容错余量下降
Producer/Consumer	重试、刷新元数据和恢复会话	超时重试需要幂等，消费重投需要业务幂等

生产环境通常部署三个或五个独立 Controller。三个 Controller 可容忍一个故障，五个可容忍两个。Controller 数量过多会增加 Raft 协调成本。

Controller 管理 Broker 注册、Topic、Partition、配置、ACL 和 Leader 变化等元数据，但不保存每个 Partition 的业务消息副本。

常见可靠性组合：

properties

default.replication.factor=3
min.insync.replicas=2
unclean.leader.election.enable=false

Producer 使用 acks=all 时，Broker 只有在 ISR 数量满足 min.insync.replicas 后才接受写入。三副本、最小两个 ISR 的配置通常可以容忍一个副本故障，并避免只剩单副本时继续确认高可靠写入。

acks=all 不表示等待全部配置副本，也不能防止 Producer 业务重复。应结合幂等 Producer 和业务幂等。

如果没有可用 ISR 且禁用 Unclean Leader Election，Partition 会保持不可用，以避免选择落后副本造成数据丢失。

通过 broker.rack 让副本分散到不同机架或可用区，避免三个副本都位于同一故障域。复制因子为三但副本同机架，不能抵御机架级故障。

跨可用区同步复制会增加延迟和带宽成本；跨地域通常使用独立集群加异步复制工具，而不是把高延迟地域直接组成单一 Kafka 集群。

Consumer Group 通过 Rebalance 把故障成员的 Partition 分配给其他成员。要实现有效接管：

Consumer 多于 Partition 时，额外实例保持空闲，可提供进程故障后的快速容量，但它们不是 Broker 副本。