消息可靠性与 Exactly Once 深度解析

面试开场白

面试官：说说 Kafka 如何保证消息不丢失？

你：需要三端协同：Producer 端设置 acks=all 和 enable.idempotence=true，保证写入 ISR 全部副本且重试不重复；Broker 端配置 replication.factor=3 和 min.insync.replicas=2，保证多副本且至少 2 个副本确认；Consumer 端手动提交 offset，先处理消息再提交，保证 At Least Once 语义。

面试官：那 Kafka 如何实现 Exactly Once（精确一次）语义？

这个追问是高级面试的核心战场。能讲清楚幂等 Producer、Kafka 事务、端到端 Exactly Once 的实现原理，才能体现对分布式系统的深度理解。

---

链式追问一：消息传递语义

Q1：Kafka 的三种消息传递语义是什么？各有什么特点？必考

回答要点：

三种语义对比：

语义	特点	消息丢失	消息重复	适用场景
At Most Once（最多一次）	消息可能丢失，但不会重复	可能	不会	日志、监控
At Least Once（至少一次）	消息不会丢失，但可能重复	不会	可能	大多数业务
Exactly Once（精确一次）	消息既不丢失也不重复	不会	不会	金融、支付

实现方式：

At Most Once：

Producer 端：
  acks=0  # 不等待确认，发完即走
  retries=0  # 失败不重试

Consumer 端：
  先提交 offset，再处理消息
  → 宕机后：offset 已提交，消息未处理 → 消息丢失

At Least Once（Kafka 默认）：

Producer 端：
  acks=all  # 等待 ISR 全部确认
  retries=MAX  # 失败重试

Consumer 端：
  先处理消息，再提交 offset
  → 宕机后：消息已处理但 offset 未提交 → 重启后重复消费

Exactly Once：

Producer 端：
  enable.idempotence=true  # 幂等性，防止重试重复写入
  transactional.id=...  # 事务，跨分区原子写入

Consumer 端：
  isolation.level=read_committed  # 只读已提交事务
  幂等消费（业务层去重）

端到端 Exactly Once：
  Producer 事务 + Consumer 原子提交 offset

本质一句话：At Most Once 牺牲可靠性换性能，At Least Once 平衡可靠性和性能，Exactly Once 追求绝对可靠但性能损失大。

面试陷阱

面试官问”Kafka 默认是什么语义”，很多候选人误以为是 Exactly Once。正确答案：Kafka 默认是 At Least Once，需要配置事务和幂等性才能实现 Exactly Once。

---

链式追问二：幂等 Producer

Q2：什么是幂等 Producer？它解决了什么问题，不能解决什么？必考

回答要点：

解决的问题：

没有幂等性时：
  Producer 发送消息 A → Broker 写入成功 → 网络故障，ACK 未收到
  Producer 重试，再次发送消息 A → Broker 再次写入
  → 消息 A 被写入两次（重复）

开启幂等性后：
  Producer 发送消息 A（PID=1001, Sequence=0）
  → Broker 写入成功 → 网络故障，ACK 未收到
  Producer 重试，再次发送消息 A（PID=1001, Sequence=0）
  → Broker 检测到相同 Sequence，丢弃重复消息
  → 消息 A 只写入一次

实现原理：

每个 Producer 实例在初始化时，会从 Broker 获取一个唯一的 PID（Producer ID）。每条发往同一分区的消息都携带一个单调递增的序列号（Sequence Number）：

消息结构（幂等时）：
  PID=1001, Sequence=0, data="msg1"
  PID=1001, Sequence=1, data="msg2"
  PID=1001, Sequence=2, data="msg3"

Broker 的去重逻辑：

// Broker 为每个 (PID, Partition) 维护最新的 Sequence Number
Map<PID, Map<Partition, Integer>> sequenceCache;

void append(PID pid, Partition partition, int sequence, Message message) {
    int expectedSeq = sequenceCache.get(pid).get(partition);

    if (sequence == expectedSeq) {
        // 正常消息，写入
        log.append(message);
        sequenceCache.get(pid).put(partition, sequence + 1);
    } else if (sequence < expectedSeq) {
        // 重复消息，丢弃（返回成功，不报错）
        return;
    } else if (sequence > expectedSeq + 1) {
        // 消息乱序，返回 OutOfOrderSequenceException
        throw new OutOfOrderSequenceException();
    }
}

配置：

enable.idempotence=true  # 开启幂等性
# 自动设置：acks=all, retries=MAX_INT, max.in.flight.requests.per.connection=5

幂等性的局限：

局限性	说明	示例
单分区	只保证单个分区内不重复	向分区 0 和分区 1 写入，分区 0 成功分区 1 失败，无法原子回滚
单会话	Producer 重启后 PID 改变	Producer 重启，新 PID 无法识别旧会话的重复消息
Consumer 侧重复	幂等 Producer 只保证写入不重复	Consumer 重复消费需业务层幂等

对比表格：

对比维度	幂等 Producer	事务 Producer
跨分区原子性	❌ 不支持	✅ 支持
跨会话幂等	❌ 不支持	✅ 支持（transactional.id）
性能开销	低	中
适用场景	单分区写入	多分区写入、流处理

本质一句话：幂等 Producer 通过 PID + Sequence Number 实现单分区、单会话的去重，防止重试导致的重复写入。

---

Q3：幂等 Producer 如何防止消息乱序？max.in.flight.requests.per.connection 有什么影响？高频

回答要点：

消息乱序场景：

Producer 发送 5 条消息到同一分区：
  msg1 (seq=0), msg2 (seq=1), msg3 (seq=2), msg4 (seq=3), msg5 (seq=4)

如果 max.in.flight.requests.per.connection > 1（允许多个未确认请求）：
  Batch1（msg1, msg2）发送成功
  Batch2（msg3, msg4）发送失败，重试
  Batch3（msg5）发送成功

  → Broker 收到顺序：msg1, msg2, msg5, msg3, msg4（乱序）

幂等 Producer 的乱序防护：

// Broker 端检测乱序
if (sequence > expectedSeq + 1) {
    // 消息乱序，返回 OutOfOrderSequenceException
    throw new OutOfOrderSequenceException();
}

// Producer 收到 OutOfOrderSequenceException
// → 停止发送，重新初始化 PID

max.in.flight.requests.per.connection 配置：

# 默认值（enable.idempotence=false）
max.in.flight.requests.per.connection=5  # 允许 5 个未确认请求

# 幂等 Producer（enable.idempotence=true）
max.in.flight.requests.per.connection=5  # 自动设为 5（幂等性允许乱序重试）

# 非幂等 Producer 需要顺序
max.in.flight.requests.per.connection=1  # 只允许 1 个未确认请求，保证顺序

对比表格：

配置	顺序保证	吞吐量	适用场景
max.in.flight=1	严格顺序	低	非幂等且需要顺序
max.in.flight=5（幂等）	允许乱序重试	高	幂等 Producer

代码示例：

Properties props = new Properties();
props.put("enable.idempotence", "true");  // 自动设置 max.in.flight=5
props.put("max.in.flight.requests.per.connection", "5");  // 幂等性允许乱序重试

// 如果需要严格顺序（非幂等）
props.put("enable.idempotence", "false");
props.put("max.in.flight.requests.per.connection", "1");  // 只允许 1 个未确认请求

注意

幂等 Producer 允许 max.in.flight.requests.per.connection=5，因为 Broker 会检测乱序并拒绝乱序消息，Producer 收到异常后会重新初始化 PID，不会真正写入乱序消息。

---

链式追问三：Kafka 事务

Q4：Kafka 事务是如何实现的？Transaction Coordinator 起什么作用？必考

回答要点：

Kafka 事务解决的问题：

• 跨分区原子性：向多个分区写入，要么全部成功，要么全部回滚
• 跨会话幂等：Producer 重启后，使用相同的 transactional.id，能识别旧会话的事务状态

事务 Producer 配置：

enable.idempotence=true
transactional.id=my-transactional-producer-1  # 全局唯一，跨会话识别同一逻辑 Producer

transactional.id 是跨会话幂等的关键：Producer 重启后，使用相同的 transactional.id 初始化，Broker 会找到之前未完成的事务并回滚，再继续工作。

事务 API：

// 初始化
producer.initTransactions();

try {
    producer.beginTransaction();

    // 向多个分区写入（原子）
    producer.send(new ProducerRecord("topic-A", key1, value1));
    producer.send(new ProducerRecord("topic-B", key2, value2));

    // 提交消费位移（作为事务的一部分）
    producer.sendOffsetsToTransaction(offsets, consumerGroupMetadata);

    producer.commitTransaction();  // 原子提交
} catch (Exception e) {
    producer.abortTransaction();   // 原子回滚
}

事务的两阶段提交：

架构示意：

Transaction Coordinator（TC，一个特殊的 Broker 角色）
    ↓
Phase 1 - Prepare：
  Producer → TC：开始事务，记录参与的分区
  TC 将事务状态写入 __transaction_state（持久化）

Phase 2 - Commit/Abort：
  Producer → TC：请求提交
  TC 向所有参与分区的 Leader 写入 Transaction Marker（COMMIT 或 ABORT）
  所有 Marker 写入成功 → 事务完成
  TC 更新 __transaction_state 为 COMPLETE

Transaction Marker 的作用：

事务消息在 Broker 中：
  msg1（PID=1001, epoch=0）   ← 事务消息，Consumer 暂不可见
  msg2（PID=1001, epoch=0）   ← 事务消息，Consumer 暂不可见
  COMMIT Marker（PID=1001）   ← TC 写入后，msg1/msg2 对 Consumer 可见

Transaction Coordinator 的关键作用：

1. 持久化事务状态：保证 TC 或 Producer 宕机后可恢复
2. 协调 Marker 写入：保证所有参与分区的原子性
3. 防止僵尸 Producer：通过 transactional.id + epoch 防止旧 Producer 的残留写入

对比表格：

对比维度	幂等 Producer	事务 Producer
跨分区原子性	❌ 不支持	✅ 支持
跨会话幂等	❌ 不支持	✅ 支持（transactional.id）
性能开销	低	中
实现复杂度	低	高（两阶段提交）

本质一句话：Kafka 事务通过 Transaction Coordinator 协调两阶段提交，向所有参与分区写入 Commit/Abort Marker，实现跨分区原子性。

---

Q5：Kafka 的事务如何防止”僵尸 Producer”问题？高频

回答要点：

僵尸 Producer 问题：

同一个 transactional.id 的 Producer 崩溃后重启，旧实例（僵尸）可能还在发送消息，与新实例产生冲突。

场景：
  T1: Producer（transactional.id=tx-1）正在发送消息
  T2: Producer 崩溃，重启新实例（transactional.id=tx-1）
  T3: 新实例开始发送新消息
  T4: 旧实例（僵尸）还在发送消息 → 与新实例冲突

解决方案：Producer Epoch

每个 transactional.id 对应一个 epoch（版本号）

Producer 重启时：
  向 TC 请求初始化 → TC 将该 transactional.id 的 epoch +1
  旧 Producer 的 epoch 已过期

旧 Producer 继续发送时：
  Broker 检测到消息的 epoch 低于当前 epoch
  → 拒绝写入，返回 ProducerFencedException
  → 旧 Producer 被"fence"（围栏），无法再写入

新 Producer 用新 epoch 正常工作

代码示例：

// Producer 初始化时
producer.initTransactions();  // 向 TC 请求初始化，epoch+1

// Broker 端检测
if (producerEpoch < currentEpoch) {
    throw new ProducerFencedException("Producer epoch is stale");
}

对比表格：

对比维度	幂等 Producer	事务 Producer
僵尸 Producer 防护	PID + epoch（单会话）	transactional.id + epoch（跨会话）
重启后防护	❌ 无防护（PID 改变）	✅ 有防护（epoch+1）
残留事务处理	❌ 无法处理	✅ TC 自动回滚

本质一句话：事务 Producer 通过 transactional.id + epoch 防止僵尸 Producer，旧实例的 epoch 过期后被 Broker 拒绝写入。

---

Q6：Kafka 的事务消息和 RocketMQ 的事务消息有什么区别？实战

回答要点：

对比表格：

对比维度	Kafka 事务消息	RocketMQ 事务消息
主要解决	多分区写入原子性	本地事务 + 消息发送原子性
实现方式	两阶段提交，Marker 标记	Half Message + 回查机制
适用场景	流处理（Kafka Streams）	业务事务 + 消息
跨系统支持	❌ 不跨 Kafka 和外部系统	✅ 支持本地事务 + 消息

RocketMQ 事务消息流程：

Producer 发 Half Message（预提交，Consumer 不可见）
    ↓
执行本地事务（写 DB）
    ↓
成功 → 发 Commit → Consumer 可见
失败 → 发 Rollback → 消息删除
超时 → Broker 回查 Producer 的本地事务状态

Kafka 事务消息流程：

Producer 开启事务
    ↓
向多个分区写入消息（Consumer 暂不可见）
    ↓
Commit → 向所有分区写入 COMMIT Marker
Abort → 向所有分区写入 ABORT Marker

本质区别：

• RocketMQ 事务消息：解决业务事务 + 消息发送的原子性（写 DB 和发消息要一致）
• Kafka 事务消息：解决多 Topic 写入的原子性（要么全部写成功，要么全部回滚）

选型建议：

场景	推荐方案
写 DB + 发消息一致性	RocketMQ 事务消息 或 本地消息表
多 Topic 写入原子性	Kafka 事务
流处理 Exactly Once	Kafka 事务 + Kafka Streams

本地消息表模式（替代 RocketMQ 事务消息）：

// 业务事务 + 发消息一致性（不依赖 RocketMQ）
@Transactional
public void createOrder(Order order) {
    // 1. 写订单 DB
    orderDao.insert(order);

    // 2. 写消息到本地消息表（同一事务）
    Message message = new Message("orders", order.getId(), order.toJson());
    messageDao.insert(message);  // 与订单在同一事务

    // 3. 定时任务扫描消息表，发送到 Kafka
    // （定时任务独立事务，失败重试）
}

// 定时任务
@Scheduled(fixedDelay = 5000)
public void sendPendingMessages() {
    List<Message> messages = messageDao.selectPending();
    for (Message message : messages) {
        producer.send(message);
        messageDao.updateStatus(message.getId(), "SENT");
    }
}

面试技巧

面试官问”如何保证写 DB 和发消息的一致性”，回答：1. 使用 RocketMQ 事务消息（Half Message + 回查）；2. 使用本地消息表（业务 DB + 消息表同一事务）；3. Kafka 事务不跨外部系统，无法直接解决此问题。

---

链式追问四：端到端 Exactly Once

Q7：Kafka 如何实现端到端的 Exactly Once？必考

回答要点：

端到端 Exactly Once 的场景：

上游 Kafka Topic A
  ↓（Consumer 消费）
处理逻辑
  ↓（Producer 写入）
下游 Kafka Topic B

要求：
  消费 Topic A + 处理 + 写入 Topic B，三者原子完成
  要么全部成功，要么全部回滚

Exactly Once 方案：

// 开启事务
producer.beginTransaction();

try {
    // 1. 消费消息
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));

    // 2. 处理消息，写入结果到下游 Topic
    for (ConsumerRecord<String, String> record : records) {
        String result = process(record);
        producer.send(new ProducerRecord("topic-B", record.key(), result));
    }

    // 3. 将消费位移作为事务的一部分提交到 __consumer_offsets
    producer.sendOffsetsToTransaction(
        getOffsets(records),
        consumer.groupMetadata()
    );

    // 4. 原子提交：结果写入 + 位移提交 同时生效或同时回滚
    producer.commitTransaction();

} catch (Exception e) {
    // 回滚：结果写入和位移提交全部回滚
    producer.abortTransaction();
}

为什么这能保证 Exactly Once？

场景1：commit 成功
  → 结果写入下游 Topic + 消费位移提交都生效
  → 下次从新位移开始消费，无重复

场景2：commit 失败/宕机
  → 两者都回滚
  → 重启后从旧位移重新消费，之前写入的结果被 abort
  → 重新处理，无重复

场景3：Producer 重试
  → 幂等 Producer 保证重试不重复写入

Consumer 端的 read_committed 隔离级别：

# Consumer 配置
isolation.level=read_committed  # 只读取已提交事务的消息（默认 read_uncommitted）

read_committed 模式下，Consumer 不会读到事务中间状态的消息，只有 COMMIT Marker 写入后，消息才对 Consumer 可见，保证了消费端的 Exactly Once。

对比表格：

隔离级别	可见消息	适用场景
read_uncommitted（默认）	所有消息（包括未提交事务）	不需要事务的场景
read_committed	只有已提交事务的消息	需要 Exactly Once 的场景

本质一句话：端到端 Exactly Once 通过将消费位移提交与结果写入绑定在同一事务里，两者原子完成，保证消费 + 处理 + 写入的精确一次。

---

Q8：Exactly Once 在 Kafka Streams 中是如何实现的？有什么性能代价？高频

回答要点：

Kafka Streams 的 EOS 实现：

一次流处理循环：
  1. Consumer 从上游 Topic 拉取消息
  2. 开启事务（beginTransaction）
  3. 执行业务处理逻辑
  4. Producer 将结果写入下游 Topic（事务内）
  5. 将消费 offset 提交到 __consumer_offsets（事务内）
  6. commitTransaction：步骤 4 和步骤 5 原子提交

如果任何步骤失败：
  abortTransaction → 结果写入和 offset 提交全部回滚
  重新从旧 offset 消费，重新处理

关键配置：

# Kafka Streams 配置
processing.guarantee=exactly_once_v2  # Exactly Once 语义（Kafka 2.5+）

# 内部自动配置
enable.idempotence=true
transactional.id=<application.id>-<task.id>
isolation.level=read_committed

性能代价：

性能数据（生产测试）：

语义	吞吐量	端到端延迟	CPU 使用率
At Least Once	100 万条/秒	~50ms	40%
Exactly Once	40 万条/秒	~200ms	80%

性能损失来源：

1. 事务协调开销
  - Producer → TC → Broker 多次网络往返
  - TC 持久化事务状态到 __transaction_state

2. read_committed 隔离开销
  - Consumer 等待 COMMIT Marker
  - 增加端到端延迟

3. 事务冲突重试
  - 多个 Producer 同时写同一分区，事务冲突需重试

对比表格：

性能维度	At Least Once	Exactly Once
吞吐量	100%	40%
延迟	50ms	200ms
CPU 使用率	40%	80%

优化建议：

# 减少事务提交频率
batch.size=32768  # 增大批量，减少事务次数

# 增大事务超时
transaction.timeout.ms=900000  # 15 分钟（默认 1 分钟）

# 减少事务冲突
num.standby.replicas=1  # 增加备份数，减少重新分配

本质一句话：Exactly Once 通过事务保证端到端精确一次，但性能损失约 60%，只在真正需要的核心业务（支付对账、库存扣减）使用。

注意

日志、监控等场景不需要 Exactly Once，使用 At Least Once 即可，配合消费端幂等处理重复消息。

---

链式追问五：消息可靠性全景

Q9：Kafka 如何保证消息不丢失？必考

回答要点：

需要三端协同：Producer 端、Broker 端、Consumer 端。

丢消息的可能环节：

Producer → Broker：
  风险：网络断开，ACK 未收到，重试后重复（幂等 Producer 解决）
  风险：acks=0/1，Broker 未持久化就宕机（acks=all 解决）

Broker 存储：
  风险：单副本，磁盘损坏（多副本 + acks=all + min.insync.replicas 解决）
  风险：页缓存未刷盘时宕机（多副本是比 fsync 更好的方案）

Broker → Consumer：
  风险：消费后宕机，offset 未提交（at-least-once，幂等消费解决重复）
  风险：先提交 offset 再处理，处理失败消息丢失（手动提交 + 处理后提交解决）

配置方案：

Producer 端：

acks=all                       # 等待 ISR 全部确认
enable.idempotence=true        # 幂等性，防止重试重复
retries=2147483647             # 无限重试
delivery.timeout.ms=120000     # 发送超时（默认 2 分钟）

Broker 端：

replication.factor=3           # 总副本数 3 个
min.insync.replicas=2          # ISR 至少 2 个副本
unclean.leader.election.enable=false  # 禁止不完整副本成为 Leader
log.flush.interval.messages=MAX_INT   # 依赖页缓存，不强制刷盘（多副本保障）

Consumer 端：

enable.auto.commit=false       # 手动提交 offset

代码示例：

// Consumer 端手动提交
while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));

    for (ConsumerRecord<String, String> record : records) {
        // 处理消息
        process(record);
    }

    // 处理完后手动提交
    consumer.commitSync();
}

监控告警：

# 监控副本同步状况
UnderReplicatedPartitions > 0 → 副本不同步，立即告警

# 监控消费积压
Lag > 10000 → 消费积压严重

本质一句话：Producer 端 acks=all + 幂等性，Broker 端多副本 + min.insync.replicas，Consumer 端手动提交，三端协同保证消息不丢失。

---

Q10：Kafka 的 Exactly Once 和数据库的事务有什么本质区别？高频

回答要点：

对比表格：

对比维度	数据库事务	Kafka Exactly Once
范围	同一数据库内的多行/多表	跨 Kafka Topic 的多个分区
隔离	MVCC，多个事务并发隔离	消息的可见性隔离（read_committed）
回滚	数据物理回滚	ABORT Marker 标记消息不可见
持久性	WAL（redo log）	ISR 多副本确认
跨系统	❌ 不跨系统	❌ 不跨 Kafka 和外部数据库

最重要的区别：

Kafka 事务不跨外部系统。如果要实现”写 Kafka + 写 MySQL 的原子性”，不能直接用 Kafka 事务，需要用分布式事务方案（如 Saga、TCC）或依赖业务幂等兜底。

示例对比：

数据库事务：
  BEGIN;
    UPDATE accounts SET balance=balance-100 WHERE user_id=1;
    UPDATE accounts SET balance=balance+100 WHERE user_id=2;
  COMMIT;
  → 两个 UPDATE 原子完成，要么都成功，要么都回滚

Kafka 事务：
  beginTransaction();
    producer.send(new ProducerRecord("topic-A", key1, value1));
    producer.send(new ProducerRecord("topic-B", key2, value2));
  commitTransaction();
  → 两个 send 原子完成，要么都成功，要么都回滚

跨系统场景（写 Kafka + 写 MySQL）：
  ❌ Kafka 事务无法保证跨系统原子性

解决方案：
  1. 本地消息表（业务 DB + 消息表同一事务）
  2. Saga 模式（补偿事务）
  3. TCC（Try-Confirm-Cancel）

本质一句话：Kafka 事务只保证 Kafka 内部的原子性，不跨外部系统；数据库事务保证数据库内部的原子性。跨系统需要分布式事务方案。

面试技巧

面试官问”如何保证写 Kafka 和写 MySQL 的原子性”，回答：Kafka 事务不跨外部系统，需要使用本地消息表（业务 DB + 消息表同一事务）或 Saga 模式实现跨系统一致性。

---

Q11：在电商下单场景中，如何用 Kafka 保证消息可靠性？实战

回答要点：

场景：用户下单 → 写订单 DB → 发 Kafka → 库存、积分、通知各自消费

架构示意：

订单服务
  ↓
写订单 DB（事务）
  ↓
发 Kafka（topic=orders）
  ↓
库存服务消费 → 扣减库存
积分服务消费 → 增加积分
通知服务消费 → 发送通知

配置层面：

# Producer（订单服务）
acks=all
enable.idempotence=true
retries=2147483647

# Broker
replication.factor=3
min.insync.replicas=2

# Consumer（库存/积分/通知）
enable.auto.commit=false

业务层面：

1. 写 DB + 发 Kafka 的原子性：

// 本地消息表模式
@Transactional
public void createOrder(Order order) {
    // 1. 写订单 DB
    orderDao.insert(order);

    // 2. 写消息到本地消息表（同一事务）
    Message message = new Message("orders", order.getId(), order.toJson());
    messageDao.insert(message);  // 与订单在同一事务
}

// 定时任务扫描消息表，发送到 Kafka
@Scheduled(fixedDelay = 5000)
public void sendPendingMessages() {
    List<Message> messages = messageDao.selectPending();
    for (Message message : messages) {
        producer.send(message);
        messageDao.updateStatus(message.getId(), "SENT");
    }
}

2. 消费端幂等：

// 库存服务（数据库唯一约束）
@Transactional
public void deductStock(ConsumerRecord<String, String> record) {
    String orderId = record.key();

    try {
        // 扣减库存（订单ID唯一约束）
        stockDao.deductStock(orderId, quantity);
    } catch (DuplicateKeyException e) {
        // 重复消费，跳过
        return;
    }
}

3. 死信队列：

// 消费失败的消息发到 DLQ
try {
    process(record);
} catch (Exception e) {
    // 发送到死信队列
    producer.send(new ProducerRecord("orders-dlq", record.key(), record.value()));
    // 不影响主流程，人工处理
}

监控告警：

监控指标：
  - 生产成功率（producer.send 成功率）
  - 消费 Lag（积压）
  - 消费异常率（process 异常）

告警阈值：
  - 生产成功率 < 99.9% → 告警
  - Lag > 10000 → 告警
  - 消费异常率 > 1% → 告警

本质一句话：本地消息表保证写 DB 和发消息一致性，消费端幂等保证 At Least Once 不重复，死信队列保证异常不影响主流程。

---

Q12：Kafka 的消息可靠性在跨机房场景下如何保障？加分

回答要点：

跨机房架构：

同城双机房：
  机房A: Broker1, Broker2, Broker3
  机房B: Broker4, Broker5, Broker6

每个分区的 3 副本分布在 2 个机房：
  Partition0: Leader(Broker1, 机房A), Follower(Broker2, 机房A), Follower(Broker4, 机房B)

配置方案：

1. 副本分布策略：

# Broker 配置
broker.rack=room-a  # 机房标识

# 分区副本分布在不同机房
# 自动分配时，会考虑 broker.rack

2. Producer 端：

acks=all
min.insync.replicas=2  # 至少 2 个副本确认（可能跨机房）

3. Consumer 端：

# Follower Fetch（Kafka 2.4+）
client.rack=room-b  # 消费者所在机房

# 效果：Consumer 优先从同机房的 Follower 读取
# → 降低跨机房流量
# → 降低延迟

风险分析：

场景	风险	解决方案
单机房故障	分区不可用（ISR 副本全在该机房）	副本分布跨机房
跨机房网络延迟	写入延迟增加	同机房 Follower Fetch
跨机房带宽成本	流量费用高	压缩 + 批量发送

性能数据：

配置	写入延迟	跨机房流量
同机房副本	~5ms	0
跨机房副本	~10ms	高
Follower Fetch	~8ms	低

本质一句话：跨机房场景通过副本分布跨机房保障单机房故障不影响数据安全，通过 Follower Fetch 降低跨机房流量和延迟。

实战案例

金融场景：同城双机房部署，每个分区的 3 副本分布在 2 个机房，单机房故障不影响数据安全，Consumer 优先从同机房 Follower 读取，降低跨机房流量 70%。

---

总结：Kafka 消息可靠性的面试答题思路

消息传递语义：

• At Most Once 牺牲可靠性换性能，At Least Once 平衡可靠性和性能，Exactly Once 追求绝对可靠

幂等 Producer：

• PID + Sequence Number 实现单分区、单会话去重
• 局限：跨分区、跨会话、Consumer 侧重复无法解决

Kafka 事务：

• Transaction Coordinator 协调两阶段提交，向所有分区写入 Commit/Abort Marker
• 跨分区原子性、跨会话幂等、防止僵尸 Producer

端到端 Exactly Once：

• 消费位移提交与结果写入绑定在同一事务，原子完成
• Kafka Streams 通过 EOS 实现，性能损失约 60%

消息可靠性配置：

• Producer：acks=all + 幂等性
• Broker：多副本 + min.insync.replicas + unclean.leader.election.enable=false
• Consumer：手动提交 + 幂等消费

跨系统场景：

• Kafka 事务不跨外部系统
• 写 DB + 发消息一致性：本地消息表或 RocketMQ 事务消息

掌握这些链式追问的答案，你就能在 Kafka 消息可靠性面试中拿高分！