# 1. Kafka 高可用架构中多 Broker/分区/副本、ISR 与 controller 选举如何保障可用性 A ISR 包含所有副本，与副本因子无关 B follower 副本直接对外提供读服务以分担 leader 压力 C controller 负责客户端的数据读写流量转发 D 只有 ISR 中的副本才能被选为新的 leader，因此可保证不丢失已提交数据 ✓ 正确答案
# 2. 分区与副本规划中分区数/副本因子、数据分布、机架感知（rack awareness）与容灾设计 A 分区数越多并行度越高，但会带来元数据与 rebalance 开销增大的代价 ✓ 正确答案 B 机架感知要求同一分区的所有副本尽量放在同一个机架 C 副本因子与分区数必须相等 D 副本因子越大，rebalance 越慢但存储成本不变
# 3. 消息可靠性三要素中 acks、min.insync.replicas、retries 与幂等 producer 如何组合 A acks=1 能保证 leader 宕机时消息不丢失 B 开启幂等后 retries 就完全不需要了 C min.insync.replicas 设置得越大可靠性越高且性能不受影响 D 幂等 producer 只能保证单分区、单会话内的顺序与去重 ✓ 正确答案
# 4. KRaft 模式运维中 Kafka 去 ZooKeeper 化后的元数据管理、controller 节点规划与迁移路径 A KRaft 模式仍强制依赖 ZooKeeper 存储元数据 B KRaft 模式下每个 broker 都可独立决策分区 leader C controller 节点数量必须为偶数 D controller 节点通过 Raft 协议选举 leader 并复制元数据日志 ✓ 正确答案
# 5. MirrorMaker 2 运维中跨集群 topic 同步、双活与主备拓扑、数据回环与冲突处理 A MM2 是同步复制，会显著增加生产端延迟 B MM2 不支持主备与双活两种拓扑 C 双活模式下通过复制前缀与内部主题避免数据回环 ✓ 正确答案 D MM2 复制时不会追踪任何偏移量
# 6. 安全运维中 SASL/SCRAM 与 SSL 认证、ACL 授权、加密传输与审计日志 A ACL 默认允许所有 principal 访问所有资源 B 认证解决"你是谁"，ACL 解决"你能做什么"，二者配合构成完整授权体系 ✓ 正确答案 C SSL 只用于认证，不能用于传输加密 D SCRAM 认证凭据一旦创建就无法更新
# 7. 常见故障排障中 leader 反复选举、ISR 频繁收缩、分区 offline、磁盘故障的处置流程 A 磁盘故障时无需迁移副本，直接格式化即可 B leader 反复选举与磁盘容量无关，只需重启 broker C 分区 offline 时直接删除副本即可恢复 D ISR 频繁收缩通常由 follower 复制慢于阈值引起，常见原因是磁盘 IO 或网络慢 ✓ 正确答案
# 8. 性能调优中 batch.size/linger.ms/compression 与 page cache、磁盘顺序写的关系 A Kafka 采用 append-only 顺序写配合 page cache，使写入吞吐远高于随机写 ✓ 正确答案 B page cache 是 Kafka 应用自身实现的内存结构 C 增大 linger.ms 一定降低吞吐 D 压缩只会增加 CPU 开销，不会提升吞吐
# 9. 消息堆积与消费延迟中消费组 lag 监控、分区分配不均、慢消费者定位与扩容策略 A 分区分配不均不会造成热点 B 增加分区数不会影响任何顺序保证 C lag 只反映生产速率，与消费速率无关 D 消费者实例数超过分区数时，多余的消费者会空闲 ✓ 正确答案
# 10. 监控指标体系中 Broker 吞吐、ISR 收缩、under-replicated partitions、网络与磁盘 IO 告警 A ISR 收缩次数不影响数据安全 B under-replicated partitions 反映有副本未同步，是需要立即关注的关键信号 ✓ 正确答案 C 磁盘使用率无需监控，Kafka 会自动回收 D active controller 数量一定为 0
# 11. 磁盘与日志管理中 segment 与索引文件、log.retention 策略、磁盘容量规划与故障处置 A 磁盘满不会影响 Kafka 分区，可自动恢复 B log.retention.bytes 只按时间删除日志 C 一个分区的日志由多个 segment 文件组成，每个 segment 含数据与索引文件 ✓ 正确答案 D compact 策略按时间删除所有消息
# 12. 集群扩缩容中 Broker 上线/下线、分区迁移（reassignment）与副本均衡的流量控制 A 分区 reassignment 期间数据会中断读写 B 上线新 broker 后无需任何迁移操作 C reassignment 无需限流，越快越好 D 下线 broker 前应确保其副本已迁移或仍有多副本存活 ✓ 正确答案
# 13. 消费者组重平衡（Rebalance）机制中 JoinGroup/SyncGroup 两阶段协议、触发条件（成员变化/订阅变化/心跳超时）与避免无限重平衡的策略？ A 重平衡只有 JoinGroup 一个阶段 B 消费处理过慢导致心跳超时被踢出组，再加入会形成无限重平衡 ✓ 正确答案 C session.timeout.ms 设置越大越容易触发重平衡 D 静态成员身份无法减少重平衡
# 14. 主题运维规范中关闭分区自动创建（auto.create.topics.enable）、主题命名与保留策略（delete/compact）选择以及删除主题的注意事项？ A 主题命名无需统一规范 B compact 策略按时间删除所有旧消息 C 删除主题是高危异步操作，数据删除后仍可随时恢复 D 生产环境应关闭 auto.create.topics.enable 防止误创建主题 ✓ 正确答案
# 15. 跨可用区部署中机架感知（rack awareness）与 min.insync.replicas 在跨 AZ 场景的配置权衡以及单 AZ 故障时的可用性边界？ A 副本因子 3、min.insync.replicas 2 时，单 AZ 故障仍可写入 ✓ 正确答案 B min.insync.replicas 设置越大，单 AZ 故障可用性越强 C broker.rack 配置与副本分布无关 D 跨 AZ 部署必须开启 unclean leader election
# 16. 配额治理中生产/消费配额（quota）如何限制客户端突发流量以及请求节流（throttle）对客户端的影响与监控？ A 配额只支持用户粒度，不支持客户端粒度 B 配额被超限时请求会被直接拒绝丢弃 C 超过配额时 Kafka 会节流客户端，在响应中携带 throttle time 让其等待 ✓ 正确答案 D 节流不会影响客户端吞吐
# 17. unclean leader election 的代价，即为何默认关闭以及允许时如何在可用性与数据一致性之间取舍、如何监控与恢复？ A Kafka 默认关闭它，因为可能丢失已提交但未同步的数据 ✓ 正确答案 B 开启它优先保证一致性，牺牲可用性 C 开启后 ISR 中副本越多越容易触发 unclean 选举 D unclean 选举不会丢失数据
# 18. Kafka 迁移中的双写迁移、流量切换与回退、消息对账与校验 A 对账只比较消息数，无需校验内容 B 迁移必须一次性全量切换，无法回退 C 双写迁移让新旧两边都积累数据，切换读流量前先对账 ✓ 正确答案 D 迁移完成后无需保留旧集群
# 19. 客户端与配额治理中连接数/请求配额、rebalance 风暴抑制与消费者组管理 A 通过 max.connections 与配额限制客户端连接与请求，防止资源被耗尽 ✓ 正确答案 B 客户端连接数越多越稳定，无需限制 C rebalance 风暴只与 broker 配置有关，与客户端无关 D 消费者组无法查看状态与 lag
# 20. 消息格式与兼容中消息格式版本、滚动升级兼容与 Broker/客户端版本矩阵管理 A 客户端版本越高，与任意 broker 都兼容 B 新版本 broker 无法读取旧格式消息 C 消息格式版本与客户端协议版本是两层，需分别管理 ✓ 正确答案 D 滚动升级无需检查版本兼容性
