Kafka 机架感知如何避免副本集中？
面试怎么回答
Kafka 通过 broker.rack 把 Broker 映射到机架或可用区，副本分配时尽量让同一分区的副本跨 rack，避免一个故障域带走全部副本。前提是 rack 标识符合真实拓扑且数量足够。上线后还要审计历史副本分布、Leader 和 ISR，并用单 rack 故障演练验证 min.insync.replicas 下仍能服务。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
Topic 有 3 副本，单台 Broker 故障也能恢复，但一个可用区断网时三个副本一起失联。
副本数解决节点故障，机架感知才把副本放置提升到机架或可用区故障域。
为 Broker 配置 rack 标识后，Kafka 在副本分配时尽量把同一分区副本分散到不同 rack；客户端也可用 rack 信息优先读取就近副本。
先定义真实故障域
rack 不一定是物理机架，也可以映射为可用区、机房或电源域。关键是同一个 rack 内的节点可能一起故障。若标识只是随意编号，副本看似分散，实际仍可能共享同一交换机或可用区。
Broker 通过 broker.rack 声明位置
每个 Broker 配置稳定的 rack 值，控制器在创建 Topic 或重新分配副本时据此分散同一分区副本。副本因子不应超过可用 Broker 数；若希望每个副本都跨故障域，rack 数量也要足够。
机架感知不是绝对隔离保证
当 rack 数少于副本数，至少有副本会落到同一 rack；集群扩缩容、手工 reassignment 和历史 Topic 也可能留下不均衡。需要定期审计分区副本的 rack 分布，而不是只确认配置项存在。
Leader 与流量仍要平衡
副本跨 rack 后，Leader 分布若倾斜，某个可用区仍会承受更多生产和消费流量。跨 rack 复制也会增加网络成本。要结合 preferred leader election、分区负载和带宽规划，让可靠性与流量均衡同时成立。
消费者也可以感知位置
支持 follower fetching 的场景中，客户端可配置 client.rack，Broker 可返回更接近客户端的副本，降低跨可用区读取流量。但这不改变消费位点和一致性边界，必须结合 Kafka 版本与远程副本读取配置验证。
面试里可以给出验收方法
列出所有 Broker 的 rack，遍历每个 Topic 分区的副本列表，检查副本是否跨 rack、Leader 是否均衡、ISR 是否健康；再模拟单 rack 下线，确认剩余 ISR 与 min.insync.replicas 还能满足写入要求。
参考资料
- Kafka Broker Configs：https://kafka.apache.org/42/configuration/broker-configs/