Kafka 集群架构与运维

• Kafka 分区与副本（replication factor）的基本概念
• ISR（In-Sync Replica）的定义与收缩/恢复条件
• controller 的作用与选举机制

Kafka 将一个 topic 的日志划分为多个分区（partition），每个分区有多个副本（replica），副本分布在不同的 Broker 上，从而在单个 Broker 宕机时仍能提供读写。每个分区有一个 leader 副本负责读写，其余为 follower 副本，follower 从 leader 拉取数据保持同步。ISR 是当前与 leader 保持同步的副本集合，只有 ISR 中的副本才会被选为新的 leader；当 follower 落后超过 replica.lag.time.max.ms 时会被移出 ISR，追平后重新加入。controller 是集群中专门负责管理元数据与分区 leader 选举的 Broker，负责分区副本的分配、leader 选举、ISR 变更等；controller 通过外部存储（ZooKeeper 或 KRaft 的 controller 节点）注册并依赖临时节点/epoch 机制防止脑裂，在 controller 宕机后由其余 Broker 重新竞选产生新的 controller。

高可用不是单一机制，而是"副本冗余 + ISR 保证一致性 + controller 协调元数据"的组合。ISR 决定了数据一致性的边界：ISR 内选举保证不丢已提交数据，ISR 外选举（unclean leader election）则可能丢数据。controller 负责把"谁能成为 leader"这一决策全局唯一化，配合 epoch 防止多个 controller 同时决策导致的分裂。

• 分区数与吞吐量、顺序性的关系
• 副本因子与可用性、存储成本的关系
• 机架感知（rack awareness）的副本分配策略

分区数是吞吐与并行度的核心：分区越多，并行消费与写入能力越强，但元数据、文件句柄与 rebalance 开销也越大，且分区内顺序保证会被削弱。一般建议按目标吞吐、消费端并行度与单分区吞吐能力估算，并考虑未来扩展。副本因子至少 2（建议 3），副本越多容错越强但存储与网络开销越大；副本因子需满足 min.insync.replicas 的约束以避免可用性不足。默认的副本分配算法会尽量将 leader 与 follower 分散到不同机架，实现机架感知：当启用 rack awareness 时，副本会尽量放置在不同机架，避免同一机架故障导致所有副本同时丢失。针对跨可用区（AZ）场景，应将副本分布到不同 AZ，并配合 min.insync.replicas 权衡可用性与一致性。

Kafka 的默认副本分配算法每次以"最少副本的机架优先"原则挑选 broker，从而保证机架内的副本数尽量均衡。机架感知的价值在于把"同批副本同时失效"的概率降到最低，是容灾设计的核心手段之一。分区数规划时还要考虑 rebalance 与 partition 迁移的成本，避免过大。

• acks=0/1/all 的语义与数据安全边界
• min.insync.replicas 与 acks=all 的配合
• 幂等 producer（enable.idempotence）的原理

acks 决定 producer 在什么情况下认为写入成功：acks=0 不等待任何确认，性能最高但可能丢消息；acks=1 等待 leader 写入成功即返回，leader 宕机时可能丢数据；acks=all 要求所有 ISR 都确认写入，可靠性最高。min.insync.replicas 指定满足"可提供服务"的最小副本数，当 ISR 少于该值时，即使 acks=all 也会报 NotEnoughReplicas 错误拒绝写入，从而防止写入到孤立的少数副本。retries 允许 producer 在瞬时错误时重试，但重试可能造成重复消息；幂等 producer（enable.idempotence=true）通过 producer 分配的 sequence 序号与 PID 去重，确保同一批次内消息不重复，规避因重试导致的重复。三者组合的推荐配置是 acks=all + min.insync.replicas=2，配合幂等与合理的 retries。

可靠性是"发送端 + 存储端 + 消费端"多层配合的结果。acks=all 只保证"所有当前 ISR 副本确认"，而 ISR 是否足够由 min.insync.replicas 决定，二者缺一不可。幂等 producer 解决的是"重试导致的重复"，它只保证单分区、单会话内的顺序与去重，事务则进一步扩展到跨分区。retries 需配合一定超时避免无限重试拖垮集群。

• KRaft 模式与传统 ZooKeeper 模式的差异
• controller 节点（quorum）与元数据日志
• 从 ZooKeeper 迁移到 KRaft 的路径

KRaft（Kafka Raft Metadata）模式用 Kafka 内置的 Raft 协议集群（controller quorum）存储集群元数据（topic、分区、config、ACL 等），不再依赖 ZooKeeper。控制器节点分为 active controller 与投票者（voter），通过 Raft 选举 leader 并复制元数据日志，active controller 负责执行分区 leader 等管理决策。controller 节点通常建议 3 或 5 个（奇数个，保证投票多数），并结合 combined（controller+broker 一体）与 dedicated（独立 controller）两种部署形态。迁移路径一般通过 kafka-reconfig / kafka-storage 工具，先生成新格式的元数据、迁移 controller，再逐步迁移 broker，最后移除 ZooKeeper，需保证版本兼容与回退方案。

KRaft 的收益是简化部署（去掉 ZooKeeper）、降低运行时复杂度、元数据规模可扩展。但 controller 节点成为新的协调者，其 quorum 的健康直接决定集群可用性，因此该节点数规划与网络隔离（如独立 controller 节点放在独立故障域）非常关键。迁移是高风险操作，需灰度并验证元数据一致性。

• MirrorMaker 2 的架构与原理
• 双活与主备拓扑的配置
• 数据回环（looping）与冲突处理

MirrorMaker 2（MM2）是 Kafka 官方的跨集群复制工具，原理是消费源集群的 topic 并写入目标集群的目标 topic，并追踪复制偏移量（remote cluster offset）以支持断点续传。它支持主备（active-passive）与双活（active-active）拓扑：双活时两个集群都接受写入，MM2 双向复制，但通过 topic 命名（如 source.topic 前缀）区分来源，避免回环；为了避免数据回环，MM2 默认跳过带复制前缀的 topic，并利用内部 topic 记录复制进度。发生冲突时，MM2 采用"最后写入者优先"或基于记录时间戳的策略处理，需运维方明确冲突解决语义。故障切换时，消费端需切换到目标集群并依据复制好的偏移量续读。

MM2 的价值在于异步复制，不增加生产端延迟，但存在复制延迟与最终一致性。双活的核心难点是冲突处理与回环防护，MM2 通过前缀与内部主题解决回环，冲突则依赖业务语义。运维上需监控 replication lag、MM2 任务的健康与复制主题的吞吐。

• 认证机制（SASL/SCRAM、SASL/PLAIN、SSL 证书）
• ACL 授权模型与配置
• 传输加密（TLS）与加密配置

认证方面，Kafka 支持 SASL/SCRAM（用户名密码，凭据可动态更新）、SASL/PLAIN、SASL/GSSAPI（Kerberos）以及 SSL 客户端证书认证。生产环境通常以 TLS 加密传输并配合 SASL 或 mTLS 认证。授权通过 ACL 实现，ACL 以 resource 类型（topic/group/cluster 等）+ 操作（read/write/describe 等）+ principal 为主体，支持通配符。审计方面，通过开启 authorizer 日志、记录客户端连接与操作来追踪权限行为，super user 角色可管理 ACL。需定期审查 ACL 与密钥轮换（SCRAM 凭据更新、TLS 证书过期）。

Kafka 安全是"认证（你是谁）+ 授权（你能做什么）+ 加密（传输不可窃听）+ 审计（记录可追溯）"四层。ACL 默认 deny-all，需显式授权；super user 可绕过 ACL。运维难点在于证书与密钥的生命周期管理、ACL 的规模与审计日志的留存。

• leader 反复选举的根因排查
• ISR 频繁收缩的原因（慢副本、网络抖动）
• 分区 offline 的判定与恢复

leader 反复选举多由 broker 不稳定（内存抖动、GC 停顿、网络抖动）导致，需检查 broker 日志、GC 情况与网络；ISR 频繁收缩通常由 follower 复制慢于 replica.lag.time.max.ms 引起，常见原因是磁盘 IO 慢、网络带宽不足、page cache 压力大，需查看 ISR 变化日志与 replica fetcher 的指标。分区 offline 表示 leader 不可用且无可用 ISR，需确认副本所在 broker 是否存活、磁盘是否满、follower 是否复制完成；恢复时先恢复 broker 再手动触发 leader 选举或分区迁移。磁盘故障先通过 mount 检测与 SMART 检查确认，及时下线故障 broker、执行分区 reassignment，将数据迁移到健康节点，并提前规划磁盘容量与替换。

排障关键是"先定位再动作"。ISR 收缩与 leader 选举是现象，根因常在副本所在的 broker 资源或网络。处置分区 offline 时，若开启了 unclean leader election 可强制选主，但会丢数据，需要权衡。磁盘故障要优先保障数据不丢，通过副本迁移实现，避免直接强制删除。

• 生产端批量参数（batch.size/linger.ms/compression）
• page cache 与操作系统缓存
• 磁盘顺序写（append-only）机制

生产端通过 batch.size 定义单批次消息的最大字节数，linger.ms 定义发送前等待累积的时间，compression 指定压缩类型（gzip/snappy/lz4/zstd），三者共同决定批次填充程度与压缩率，从而提升吞吐、降低网络往返。Kafka 采用 append-only 的日志模型，写入是顺序追加到磁盘，配合操作系统 page cache，写入先进入内存缓存由内核异步刷盘，读热点数据也命中 page cache，从而大幅降低磁盘 IO 延迟。调优时需权衡吞吐与延迟：增大 batch.size 与 linger.ms 提高批处理吞吐但增加延迟；压缩率高但消耗 CPU。运维上要监控 page cache 命中率、磁盘顺序写与随机读的比例。

Kafka 高性能的根基是"顺序写 + page cache"。顺序写让磁盘能利用顺序 IO 的高吞吐，page cache 让热数据驻留内存。生产端的批处理是"更多数据一次写"，三种机制叠加构成 Kafka 的高吞吐能力。调优要在吞吐与延迟间取舍，并避免 flush 过于频繁打乱顺序性。

• 消费组 lag 的监控与意义
• 分区分配不均与热点问题
• 慢消费者的定位方法

lag 是"最新消息偏移量 - 消费组已提交偏移量"，反映积压程度，通常通过 kafka-consumer-groups 命令或监控工具（如 Burrow、Kafka Exporter）采集。分区分配不均指消费组内各消费者持有的分区数不均衡，导致部分消费者过载、部分空闲，产生热点；需检查协调者的分配均衡性。慢消费者定位通过查看每个分区的消费速率、单条消息处理耗时、下游依赖（DB、外部 API）的耗时定位瓶颈。扩容策略：增加消费者实例（受分区数上限约束，消费者数超过分区数会空闲）、增加分区数（需注意分区数只增不减及顺序影响）、优化消息处理逻辑或引入并行处理。

堆积的本质是"生产速率 > 消费速率"或"消费端能力不足"。扩容前先确认是产能不足还是下游慢，盲目加消费者若分区数不够则无效。增加分区数能提升并行度但破坏分区内顺序，需权衡。lag 监控要设置告警阈值并区分"短期积压"与"持续消费不动"。

• Broker 吞吐与进出速率指标
• ISR 收缩与 under-replicated partitions
• 网络与磁盘 IO 指标

核心监控指标包括：Broker 整体吞吐（bytes-in/bytes-out、messages-in）、分区级别吞吐、ISR 收缩次数（isr-shrink-rate）、under-replicated partitions（URP，副本数低于副本因子的分区数）、active controller 数量、网络（网络吞吐、连接数、request 延迟）、磁盘（磁盘使用率、IO 等待、磁盘满）。ISR 收缩与 URP 是反映副本健康与数据安全的关键告警，URP>0 说明有副本未同步，需立即关注；磁盘使用率接近阈值易触发只读或 offline。告警应分级：URP 持续、ISR 频繁收缩、磁盘高水位为高优先；吞吐波动、请求延迟为中优先。防止告警风暴需设置持续时间与聚合。

Kafka 监控看的是"数据是否安全 + 是否可用 + 是否够快"。URP 与 ISR 收缩直接关系到数据一致性与可用性，是最重要的健康信号；磁盘与网络是资源瓶颈的预警。监控要结合 JMX 指标与集群视角，并关注异常状态（如 controller 个数不为 1）。

• segment 与 .log/.index/.timeindex 文件结构
• log.retention 策略（时间/大小/紧凑）
• 磁盘容量规划与预留

Kafka 每个分区的日志由多个 segment 文件组成，每段一个 .log 数据文件、.index 偏移量索引与 .timeindex 时间戳索引，segment 按 log.segment.bytes 或 log.roll 时间滚动。日志保留策略主要有 log.retention.hours（按时间）、log.retention.bytes（按大小）与 log.cleanup.policy=compact（按 key 紧凑）。磁盘容量规划需考虑：单分区数据量 x 副本因子 x 保留时长 + 预留缓冲（如 30%），并叠加写入峰值与 segment 滚动开销。磁盘故障处置：先确认故障隔离，下线 broker，执行分区 reassignment 迁移副本到健康节点，再替换磁盘；开启 min.insync.replicas 配合副本保证数据不丢。

磁盘是 Kafka 的存储核心，容量规划要"留余量"，避免磁盘满触发分区只读或不可用。log.retention 的删除是异步的（按 segment 粒度），实际占用会略高于配置值。compact 策略用于按键保留最新值，适合日志表场景。磁盘故障处置优先保证"副本仍在"。

• Broker 上线/下线的流程
• 分区 reassignment 的原理与工具
• 副本均衡与流量控制

Broker 上线是先启动新 broker 使其注册到集群，再执行 reassignment 把部分分区迁移过去以均衡负载。Broker 下线前先确认副本已迁移到其他节点，再优雅下线，避免分区 offline。分区迁移通过 kafka-reassign-partitions 工具生成 reassignment json，把分区 leader/follower 从一个 broker 迁移到另一个，执行时可设置 throttle 限制迁移带宽，避免迁移骤增拖垮正常业务流量。副本均衡通过 reassignment 把 leader 与副本调度到负载低的节点。迁移后需移除 throttle 并确认集群均衡。

扩缩容的关键是"平滑 + 可控"。reassignment 是异步复制的过程，数据从源节点复制到目标节点，期间不中断读写，但会占用带宽与磁盘 IO，因此用 throttle 限流。下线 broker 前必须保证其副本已迁移或仍有多副本存活，否则会因副本数不足导致分区不可用。

• JoinGroup/SyncGroup 两阶段协议
• Rebalance 触发条件（成员、订阅、心跳）
• 无限重平衡（rebalance storm）的成因

消费者组重平衡由协调者（group coordinator）触发，采用两阶段：第一阶段 JoinGroup，各成员向协调者报告订阅信息，协调者选出 leader 并汇总成员信息；第二阶段 SyncGroup，leader 根据分区分配策略计算出每个成员的分区分配方案，协调者把方案分发给所有成员。触发条件包括：成员增减（加入/离开/心跳超时被判定离组）、订阅主题变化、分配策略变化。如果成员在 rebalance 期间频繁地加入退出（如消费超时、协调者切换、心跳超时），会导致 rebalance 反复进行，即"无限重平衡"（rebalance storm），严重影响消费。避免策略：合理设置 max.poll.interval.ms、session.timeout.ms、heartbeat.interval.ms 与 max.poll.records，使消费处理时间在允许范围内；及时提交偏移量；避免过大的消费组；使用静态成员（static membership）减少重平衡。

Rebalance 是协调一致性的机制，但也带来消费中断。无限重平衡的根因通常是"消费处理太慢导致心跳超时被踢出组，再加入又触发 rebalance"，形成循环。通过调整 poll 相关参数、控制单次 poll 的消息量、提升处理能力可打破循环。静态成员用 group.instance.id 固定成员身份，减少成员变化引起的重平衡。

• auto.create.topics.enable 的关闭
• 主题命名规范
• delete 与 compact 保留策略的选择

生产环境应关闭 auto.create.topics.enable 或在服务端显式管理，避免因误写、类型错误导致主题被意外创建，产生脏数据。主题命名规范应统一（如 业务域.来源.用途），配合 description 与 TAG 管理主题元数据。保留策略选择：delete 是按时间/大小删除旧消息，适合日志、事件流等数据；compact 是按 key 保留最新值，适合键值对、表快照类数据，且日志不能无限增长。删除主题前需：确认 delete.topic.enable=true、确认无消费者依赖、评估数据可删除性，删除后数据不可恢复，应谨慎并在测试环境演练。删除是异步的，需观察主题从元数据中消失。

主题运维规范的核心是"可控、可追溯、防误操作"。自动创建关闭是防止脏数据与资源浪费的第一道防线。命名规范让运维可快速判断主题归属与用途。删除是高危操作，Kafka 删除主题是异步删除数据，之前必须确认无消费依赖与数据价值。

• 跨 AZ 的机架感知配置
• min.insync.replicas 在跨 AZ 的权衡
• 单 AZ 故障时的可用性边界

跨 AZ 部署时，将每个 AZ 视为一个机架，通过 broker.rack 配置机架感知，使副本均匀分布在多个 AZ，避免单 AZ 故障导致所有副本丢失。min.insync.replicas 的设置在跨 AZ 场景需权衡：若设为 2（副本因子 3，分布 3 个 AZ），则单个 AZ 故障尚有 2 个副本在 ISR，仍可写入；若设为 3，则任一 AZ 故障都会导致 ISR 不足而拒绝写入，牺牲可用性换数据安全。单 AZ 故障时的可用性边界为：副本因子为 R、min.insync.replicas 为 M 时，只要存活的 ISR 副本数 >= M 集群仍可写入，>= 1 仍可读；若 ISR 少于 M 则写入被拒绝，服务质量降级为只读或不可用。

跨 AZ 的权衡是"可用性 vs 数据安全"。副本因子 3 + min.insync.replicas 2 是常见折中，允许单 AZ 故障仍可写入，同时保证数据至少有两份。机架感知确保副本不会被放置在同一个 AZ，是现代容灾的基石。

• 生产/消费配额的类型与配置
• 配额限制突发流量的机制
• 节流（throttle）对客户端的影响

Kafka 配额支持客户端粒度（默认按 client-id）与用户粒度，分为网络带宽配额（producer/consumer byte rate）与请求速率配额（request rate）。当客户端超过配额时，Kafka 会节流（throttle）：在响应中携带 throttle time，客户端需等待该时间后再继续请求，从而平滑突发流量，防止单个客户端占满集群资源。客户端可感知节流（通过记录节流时间或观察响应延迟），表现为请求变慢、吞吐下降。监控方面通过 JMX 指标（如 quota 相关指标、throttle 时间）观察哪些客户端被节流及节流程度，并据此调整配额或客户端行为。

配额是"多租户资源治理"的重要手段，防止一个客户端拖垮整个集群。节流是软性的、按客户端限速，不拒绝请求，只是延迟。配额过低会导致正常业务被限速，需结合监控与业务需求调整。生产与消费配额分开设置，满足不同场景。

• unclean leader election 的含义
• 默认关闭的原因（数据丢失）
• 可用性与一致性的取舍

unclean leader election 允许在 ISR 为空时，从 ISR 外的副本（落后副本）中选择新 leader。默认关闭，因为落后副本可能缺失已提交但未同步的数据，选它为 leader 会导致这些数据丢失，破坏数据一致性。开启它时，以牺牲一致性换取可用性：在 leader 故障且 ISR 无可用副本时仍能提供服务，适合"可用性优先于数据完整性"的业务。监控上应关注 isr-shrink 与 unclean-election 相关指标，持续观察是否有数据丢失。恢复时，一旦 ISR 中副本恢复，应尽快让落后副本追上，必要时通过 reassignment 或重新设置 leader 恢复 ISR 健康。

这是"CAP 权衡"的典型：unclean 选举优先可用性（A），牺牲一致性（C）。默认关闭体现 Kafka 默认"数据正确优先"。是否开启取决于业务：日志、可重放数据可接受丢失；账务、交易不可接受。开启后必须加强监控与数据对账，评估丢失风险。

• 双写迁移方案
• 流量切换与回退策略
• 消息对账与校验方法

Kafka 迁移常用双写（dual-write）方案：先在旧集群上新增对目标集群的写入（通过应用双写或 MirrorMaker），使新旧两边都积累数据，再逐步切换读流量。流量切换采用灰度策略，先迁移部分分区/部分消费组，观察对账结果后再全量切换。回退预案：若切换后发现问题，可回退到旧集群或保留旧集群数据用于回退。消息对账与校验：通过对比新旧集群的 topic 消息数、偏移量、抽样校验消息内容与键值，确认数据一致性；对账工具可比较消息总数、最后写入时间、checksum 等。最后移除旧集群写入，完成迁移。

迁移的核心是"可回滚 + 可验证"。双写保证新旧两边都有数据，切换不丢消息；对账确保两边一致；回退预案降低风险。对账需处理"双写期间部分消息未同步到目标"的差异，通过补写或重放解决。迁移完成前保留旧集群作为安全网。

• 连接数与连接管理
• 客户端请求配额
• rebalance 风暴抑制

客户端连接数治理：通过 broker 的 max.connections 限制单个 ip 或 broker 总连接数，避免客户端连接风暴耗尽资源；客户端应复用连接、合理管理连接池。请求配额通过 quota 限制单个客户端的请求速率与带宽，防止突发流量冲击。rebalance 风暴抑制：通过调整 poll 参数、静态成员、避免频繁加入退出、控制消费组规模来减少重平衡。消费者组管理：通过 kafka-consumer-groups 查看组状态与成员、lag，处理 inactive 组、清理无消费者组，审计组的管理权限。

客户端治理是"防滥用、保稳定"。连接数、请求配额限制资源占用，rebalance 抑制保障消费稳定，消费者组管理用于可观测与清理。运维需平衡"限制"与"易用"，配额过低会误伤正常业务，需结合监控调整。

• 消息格式版本（message format version）
• 滚动升级的兼容策略
• Broker 与客户端版本矩阵管理

Kafka 消息格式版本（message format version）控制消息在磁盘上的编码格式，通过 broker 的 log.message.format.version 或 topic 配置指定。升级时，新版本 broker 可读旧格式消息，但消息格式升级需要先升级 broker 再逐步切换 message format，保证新旧消息兼容。滚动升级指逐个重启 broker，期间集群保持可用，需保证版本兼容（新版本 broker 支持旧版本协议）。客户端版本矩阵：客户端版本与 broker 版本需兼容，低版本客户端无法使用新功能，高版本客户端可连接低版本 broker（在一定范围内）；管理上需统一客户端版本、建立兼容矩阵，避免升级后功能失效或协议不兼容。升级前检查 broker 日志、API 兼容性，并保留回退路径。

兼容性管理是"平滑升级"的保障。消息格式与协议版本是两层：消息格式决定磁盘/跨版本读取，协议版本决定客户端交互。升级 broker 时先确认目标版本与当前版本的兼容矩阵，消息格式升级是单独一步，需在 broker 升级后显式执行。版本矩阵治理避免"客户端过老导致功能缺失"或"协议不兼容导致连接失败"。