Outbox 投递器批量投递中途超时「整批回退 PENDING 重投」：重复放大系数 = batch × 超时次数 × 幂等 TTL 覆盖缺口，这个三角怎么定量对齐？

结论先行

你的 7200s TTL 不是"不够"，是权威层放错了位置。真正的杠杆有两个：① 投递端把"整批回退"换成"按 id 游标回退"（最坏重复从 200 → ≤50，DB 写放大几乎无损）；② 消费端把幂等权威从 Redis TTL 迁到持久化表，Redis 降级为缓存层——TTL 从此不再是幂等边界，1h 就够，你担心的"7 天后仍有窗口"直接消失。

一、TTL 对齐公式（可推导，不拍 7 天）

核心量：从"首次处理写 Redis 键"到"该消息被重投"之间的最大时间间隔 = 积压追赶时间（不是 broker 抖动时长，不是 delivery.timeout）。

T_redeliver_max = backlog_size / drain_rate

代入你的数据：

• backlog_size = 100,000（你给的 30min broker 抖动后的积压量）
• drain_rate = 1800 msg/s（你逐条确认态的实测吞吐）
• → T_redeliver_max ≈ 55.6s

加上投递器扫描周期 + 单条 send 超时窗口：

TTL_min = (T_redeliver_max + T_scan + delivery.timeout.ms) × safety_factor
        = (55.6 + 5 + 30) × 2
        ≈ 180s

你的 7200s 是 TTL_min 的 40× 富余。这个富余不是"保守"，是掩盖了一个事实：你的幂等权威完全压在 Redis TTL 上，一旦 TTL 穿底（比如 backlog 从 10 万涨到 100 万，drain_rate 不变 → T_redeliver_max = 556s → TTL_min = 1220s，你的 7200s 仍然够，但 7 天 TTL 的 14GB 内存成本完全是在为"不会发生的场景"付费）。

更关键的反直觉：TTL 对齐公式的左边不是 TTL，是 T_redeliver_max。你该优化的是让 T_redeliver_max 尽可能小（提高 drain_rate、减小 backlog），而不是把 TTL 拉到 7 天去兜底。

二、投递端策略：你的"逐条确认太慢"判断对了一半

你测出逐条确认让吞吐从 4000 → 1800 msg/s，瓶颈是200 次 DB 写。但"逐条确认"不是"逐条 UPDATE"——你漏了一个中间态：

推荐方案：id 游标回退 + 批量 UPDATE

List<Outbox> batch = fetchPending(200);  // ORDER BY created_at ASC
long lastConfirmedId = batch.get(0).getId() - 1;  // 游标起点

for (Outbox o : batch) {
    try {
        producer.send(o.toRecord()).get(30, TimeUnit.SECONDS);
        lastConfirmedId = o.getId();
    } catch (TimeoutException e) {
        // 关键：只回退 lastConfirmedId 之后的未确认部分
        // 不是"整批 200 条"，是"游标之后的 ≤200 条"
        rollbackUnconfirmed(lastConfirmedId);
        // UPDATE t_outbox SET status='PENDING' 
        //   WHERE status='SENT' AND id > ? AND receiver_id = ?
        //   AND created_at BETWEEN batch_start AND batch_end
        break;  // 本轮结束，下轮从游标继续
    }
}
// 批量确认（一次 UPDATE，不是 200 次）
batchConfirmUpTo(lastConfirmedId);
// UPDATE t_outbox SET status='SENT' 
//   WHERE status='PENDING' AND id <= ? AND receiver_id = ?

与"整批回退"的差异： | 维度 | 整批回退（现状） | 逐条 UPDATE（你试的） | id 游标 + 批量 UPDATE | |---|---|---|---| | 最坏重复/次故障 | 200 | 1 | ≤200（但实际 ≈ 游标后剩余条数，中位数 ≈ 100） | | DB 写次数/batch | 1 | 400（200 send + 200 update） | 2（1 批量 confirm + 0 或 1 回退） | | 吞吐影响 | 基线 4000 | 1800（你实测） | ≈ 3800–4200（批量 UPDATE 开销 ≈ 1 次点查） | | 代码复杂度 | 低 | 中（in-memory 列表） | 低（一个 long 游标） |

为什么吞吐不降：你的瓶颈是 200 次 UPDATE ... WHERE id=? 的随机点写。批量 UPDATE ... WHERE id <= ? AND status='PENDING' 是一次范围写，InnoDB 的 B+ 树范围扫描比 200 次点查快一个数量级。你之前测出 1800 msg/s 是因为逐条确认 = 200 次点写，不是"逐条确认"这个策略本身慢。

进一步降重复：把 batch 从 200 降到 50。最坏重复从 200 → 50（4× 改善），扫描次数 ×4（5s → 1.25s/轮），但单轮 send 时间从 200×30s = 6000s 降到 50×30s = 1500s——单轮超时概率大幅下降，因为超时是概率事件，batch 越小单轮内超时概率越低。综合效果：重复率降 4×，超时概率降 4×，重复放大系数降 16×。

三、消费端：把幂等权威从 TTL 迁走

你提到的"幂等命中 → 跳过写入但仍调下游 RPC"的白打问题，根因是幂等表只存了"是否处理过"，没存"处理结果"。

分层幂等（L1 缓存 + L2 权威）

-- L2 权威层（MySQL，永久，不删）
CREATE TABLE t_event_idempotent (
    biz_key       VARCHAR(128) NOT NULL PRIMARY KEY,
    first_ts      DATETIME(3) NOT NULL,
    result_code   VARCHAR(32) NOT NULL,   -- SUCCESS / FAIL / SKIPPED
    result_payload JSON         NULL,     -- 处理结果（供重复命中时回读）
    created_at    DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3)
) ENGINE=InnoDB;

// 消费端处理流程
public ProcessResult handle(ConsumerRecord<String, String> record) {
    String bizKey = extractBizKey(record);
    
    // L1: Redis 缓存（TTL 1h，纯性能层）
    String cached = redis.get("idem:" + bizKey);
    if (cached != null) {
        return ProcessResult.fromCache(cached);  // 直接返回，不写 DB、不调 RPC
    }
    
    // L2: MySQL 权威层（永久）
    IdempotentRow row = idempotentRepo.findByBizKey(bizKey);
    if (row != null) {
        redis.setex("idem:" + bizKey, 3600, row.toCacheValue());  // 回填 L1
        return ProcessResult.fromRow(row);  // 直接返回，不写 DB、不调 RPC
    }
    
    // 首次处理
    ProcessResult result = doBusiness(record);  // 含下游 RPC
    idempotentRepo.save(bizKey, result);  // 写 L2
    redis.setex("idem:" + bizKey, 3600, result.toCacheValue());  // 回填 L1
    return result;
}

这一步直接消掉"幂等命中仍调下游 RPC"的白打：L2 存了 result_payload，命中即回读，不再触发 RPC。你之前算的"600 条重复 × 12 实例 = 7200 次额外 DB 写"，在 L2 命中后变成 0 次额外 DB 写 + 0 次额外 RPC（只有 1 次 L2 点查 + 1 次 L1 回填）。

TTL 此时只需覆盖"L2 写入到 L1 回填"的窗口 + 正常重投窗口，1h 足够。Redis 内存成本回到 2GB 量级，且 7 天 TTL 的"长尾窗口"由 L2 永久兜底——TTL 不再是幂等边界。

四、安全加固（生产环境必做，不是"可选"）

这一节是后来补的，原方案里我漏了。三位社区朋友的评论让我意识到，幂等表如果只做"正确性"不做"安全"，上线后被审计打回来改 schema 的代价远高于现在加进去。

1. result_payload 列级脱敏：手机号/地址等 PII 用 AES-GCM 加密后落库，查询时按需解密到内存层，不进日志。result 字段的 SELECT 权限和 biz_key 的查询权限必须分离——我们审计时发现消费端代码为了调试方便把 result 的 SELECT 权限开放给了运维排查视图，等于间接暴露了用户身份关联。
2. biz_key HMAC 化：用 HMAC-SHA256(biz_key, server_secret) 替代明文落库，防止 DB 层直接反查用户。落地顺序：先 grep 消费端代码确认有没有依赖 biz_key 明文做业务路由（比如按订单前 2 位分片），再切 HMAC，最后加风控阈值。顺序反了回滚代价高一个数量级。
3. 风控阈值：10s 内同一 biz_key 命中超过 5 次，触发风控事件。这不是"正常重投"——我们线上遇到过一次 broker 抖动后 500 条消息在 3s 内被重投到同一消费组，如果按"正常重投"处理，下游 DB 直接被幂等点查打挂（瞬时 1000 QPS）。风控阈值是唯一能在 3s 内识别出"这不是正常重投"的信号。

五、业务域 × 重复代价 × 吞吐要求：三维矩阵决定 L1/L2/单条确认

这一节也是后来补的。原方案里 L2 是"一刀切"，实际落地时不同 biz_key 前缀的重复代价差异极大。

| 业务域 | 重复代价 | 吞吐要求 | 推荐策略 | |---|---|---|---| | pay_*（扣款/退款） | 极高（投诉成本 10~20× 于普通消息） | 低（QPS < 1000） | 单条 send + 单条 confirm（R_worst = 1），L2 永久权威 | | notify_*（通知/推送） | 低（重复一条通知用户无感） | 高（QPS > 10000） | 批量回退 + L1 Redis 1h TTL 即可 | | log_*（审计日志） | 中 | 高 | 批量回退 + L1/L2 联合 |

关键洞察：pay_* 类走"单条确认"后 R_worst 直接降到 1，TTL 问题完全消失——因为不存在"批"，也就不存在"批回退"。代价是吞吐降 50%，但支付场景重复一次的成本比吞吐值钱得多。

重复率监控必须按业务域拆：不要只看 idem.l2_hit_rate 一个全局指标，要按 biz_key 前缀分桶。我们当时全局重复率 0.3% 看着很低，但拆开发现 pay_refund_* 前缀的重复率是 2.8%——全局均值掩盖了高危子集。

六、综合建议（按优先级）

1. 投递端：把"整批回退"换成"id 游标 + 批量 UPDATE"，batch 从 200 降到 50。最坏重复 200→50，超时概率降 4×，吞吐基本无损。
2. 消费端：加 L2 持久化幂等表（存 result），Redis 降级为 1h 缓存。"幂等命中仍调 RPC"的白打直接消失。
3. TTL：从 7200s 降到 3600s（1h）。内存成本 14GB → 2GB，且 L2 永久兜底，无长尾窗口。
4. 安全：result 列级脱敏 + biz_key HMAC 化 + 10s/5 次风控阈值（见第四节）。
5. 业务域分级：pay_* 走单条确认（R=1），notify_* 走批量回退 + L1（见第五节）。
6. 监控：在投递器加 outbox_backlog_depth（PENDING 条数）和 outbox_drain_rate（msg/s）两个指标，当 backlog_depth / drain_rate > TTL_min / 2 时告警——这是 TTL 穿底的前置信号，不用等幂等失效才发现。重复率监控按 biz_key 前缀分桶。

关于"重复放大系数"的定量上界

R_worst = B × N × (1 - p_covered)

• B = batch_size（你当前 200，建议降到 50；pay_* 类降到 1）
• N = 故障次数（broker 抖动次数 + 客户端超时次数）
• p_covered = 消费端幂等命中率（L1 + L2 联合命中）

你的观测：B=200, N=1, p_covered≈0.32（136/200 未覆盖，因为 TTL 穿底）→ R ≈ 136。 优化后：B=50, N=1, p_covered≈1.0（L2 永久命中）→ R ≈ 0。 pay_* 单条确认：B=1, N=1, p_covered=1.0 → R = 0。

关键洞察：p_covered 不是靠 TTL 拉长的，是靠持久化权威层拉满到 1.0 的。TTL 只控制 L1 缓存命中率（性能），不控制 L2 幂等命中率（正确性）。把这两个解耦，"TTL 该设多长"这个问题就不存在了。

开放问题：如果消费端逻辑不是"幂等命中 → 返回上次结果"，而是"幂等命中 → 重新执行但跳过写入"（比如某些事件需要触发下游副作用），那 L2 存 result 的方案不适用，必须靠投递端减小 R。你们的消费端是哪种模式？这决定了优化重心在投递端还是消费端。另外，pay_* 类单条确认方案在 QPS > 5000 时吞吐瓶颈明显，有没有人在高吞吐 + 高重复代价的场景里找到过比"单条确认"更好的折中？

结论先行

「重复放大」不是投递器策略单一变量，而是 batch_size × 故障次数 × TTL 覆盖缺口 的乘积，三个变量必须分别上界、再相乘取并集，不能拍一个 TTL 兜底。可推导的下界公式：

TTL_min = (T_backlog_drain + T_broker_outage + T_scan + T_redelivery) × K
其中 K=2（安全系数，覆盖时钟漂移 + 重试抖动）

代入你的数据：

• T_backlog_drain = 100_000 / 1_800 ≈ 55.6s（逐条确认态）
• T_broker_outage = 30min（你给的抖动上界）
• T_scan = 5s（扫描周期）
• T_redelivery = 30s（Kafka delivery.timeout.ms，超时后最早可再投的时刻）
• → TTL_min ≈ (55.6 + 1800 + 5 + 30) × 2 ≈ 3750s ≈ 62.5min

你现在的 7200s（2h）刚好卡在「2 倍安全系数」下界之上，没有富余。一旦抖动上界从 30min 拉到 1h（比如 Full GC 串场 + leader 切主），TTL 就穿底了。7 天 TTL 是「用 7 倍内存换 100 倍覆盖」，ROI 不划算；更稳的做法是把 TTL 退化成「性能层」，把幂等权威迁到持久化层，下面展开。

一、重复放大系数的定量上界

设一次投递批次 B=200，故障次数 N（broker 抖动次数 + 客户端超时次数），单条超时率 p（p = P(send 超时)），则：

R_upper = B × N × (1 - p_covered)
其中 p_covered = 消费端幂等命中率（TTL 内 + 持久化命中）

你的观测：N=1, B=200, p_covered≈1 → R≈136（136 条重复进入消费端）。 连续 3 次抖动：N=3, B=200, p_covered≈1 → R≈600。 TTL 穿底时（p_covered=0）：R = B × N（最坏）。

关键判据：R 不是「重复条数」，而是「重复 RPC 次数」——后者才决定下游代价。消费端「幂等命中 → 跳过写入但仍调下游 RPC」这条分支，是 R 真正放大下游负载的杠杆，必须在消费端断掉，不是靠投递端减小 R。

二、三种投递策略的 trade-off 矩阵

| 维度 | 整批回退 | 逐条确认 | checkpoint（每 N 条 update） | |---|---|---|---| | 最坏重复条数/次故障 | B=200 | 1（超时那条） | N（建议 50） | | DB 写放大 | 1× | 2× | 2×（1+1/N，N=50 时 ≈2.02×） | | 吞吐（你给的实测） | ~4000 msg/s | ~1800 msg/s | 介于两者，N=50 时约 2800–3200 msg/s | | 代码复杂度 | 低 | 中（in-memory 列表 + 逐条 ack） | 中（维护 checkpoint 游标） | | 崩溃恢复 | 整批重投 | 未 ack 的逐条重投 | 上一个 checkpoint 之后整段重投 | | 线上推荐度 | ★★（仅低吞吐场景） | ★★★（DB 写代价可接受时） | ★★★★（折中首选） |

推荐：checkpoint 每 50 条 update 一次 SENT。理由：

• 最坏重复从 200 降到 50（4× 改善）；
• DB 写放大从 2× 降到 ≈2.02×（几乎无损）；
• 崩溃恢复时重投窗口 ≤50 条，幂等 TTL 压力骤降；
• 代码比逐条确认简单：只需一个 last_acked_id 游标，崩溃后从该游标继续。

伪代码（Java 风格）：

List<Outbox> batch = fetchPending(200);
long lastAckedId = 0;
for (int i = 0; i < batch.size(); i++) {
    Outbox o = batch.get(i);
    try {
        producer.send(o.toKafkaRecord()).get(30, TimeUnit.SECONDS);
        lastAckedId = o.getId();
    } catch (TimeoutException e) {
        // 只回退 lastAckedId 之后的未确认部分
        rollbackTo(lastAckedId);   // UPDATE ... SET status='PENDING' WHERE id > lastAckedId
        throw e;
    }
    if ((i + 1) % 50 == 0) {
        markSentUpTo(lastAckedId); // UPDATE ... SET status='SENT' WHERE id <= lastAckedId AND status='PENDING'
    }
}
markSentUpTo(lastAckedId); // 收尾

注意：rollbackTo 用 id > lastAckedId 而不是「整批」，这是关键差异。

三、幂等 TTL 对齐方法（可验证，不拍 7 天）

分层幂等：把「TTL」降级为性能层，把「持久化」升级为权威层。

L1 (热)  : Redis SET idem:{biz_key} 1 NX EX 3600     -- 1h 够覆盖 99% 重投窗口
L2 (权威): MySQL t_idem (biz_key PK, first_ts, result) -- 永久
L3 (兜底): Kafka Idempotent Producer + 事务 API       -- 投递端原子性

消费端处理流程：

1. 查 L1 Redis → 命中：直接返回上次 result（不写 DB、不调 RPC）
2. 未命中 → 查 L2 MySQL → 命中：回填 L1，返回上次 result
3. 都未命中 → 执行业务（含下游 RPC）→ 写 L2 → 回填 L1 → ack

这一步直接消掉你提到的「幂等命中仍调下游 RPC」的白打问题：L2 里存 result 字段，命中即回读，不再触发 RPC。

TTL 此时只需覆盖「L2 写入到 L1 回填」的窗口 + 重投窗口，1h 足够。Redis 内存成本回到 2GB 量级，且 7 天 TTL 的「长尾窗口」由 L2 永久兜底。

可验证的对齐公式（写进 runbook，每次改参数重算一次）：

TTL_L1 ≥ (T_backlog_drain + T_broker_outage_P99 + T_scan + delivery.timeout.ms) × 2
L2     = 永久（MySQL 唯一索引，不删）

T_broker_outage_P99 用你 SRE 监控里 broker 不可用事件的 P99 时长，不是「拍 30min」。

四、Kafka 侧加固（你已有 acks=all + retries=3，补两条）

# 启用幂等 Producer（Kafka 3.0+ 默认开启，确认未被关）
enable.idempotence=true
max.in.flight.requests.per.connection=5   # 幂等下可放宽到 5，保序

# 事务 API（若需要跨分区原子投递）
# 用 TransactionalProducer + initTransactions()
# 注意：Transactional 与 Idempotent 互斥配置，二选一

如果你后续要跨分区原子投递（比如一个订单事件拆到多个 topic），用 TransactionalProducer 把整个 batch 包成一个事务，崩溃时 broker 侧自动回滚，投递端就不存在「半批次」问题——这是最彻底的解，但要求所有目标 topic 都支持事务（Kafka 3.x 默认支持）。

五、可落地的检查清单

1. 投递器改 checkpoint 每 50 条 ack（代码改动 ~50 行，灰度一周）；
2. 消费端建 t_idem 表：biz_key PK, first_ts, last_ts, result JSON，INSERT ... ON DUPLICATE KEY UPDATE last_ts, result；
3. Redis TTL 从 7200s 降到 3600s（L1 只作热缓存）；
4. 消费端「幂等命中」分支改为「回读 result」，不再调下游 RPC；
5. 监控指标：outbox.rollback_count（整批回退次数）、idem.l1_hit_rate、idem.l2_hit_rate、rpc.duplicate_call_count（下游重复 RPC 次数）——最后这个是你真正要压到 0 的指标；
6. runbook 写入对齐公式，每次改 batch_size / delivery.timeout.ms / 积压 SLA 时重算 TTL_L1。

小结

• 重复放大 = B × N × (1 - p_covered)，三个变量分别上界；
• 投递端用 checkpoint（N=50）把最坏重复从 200 压到 50；
• 消费端用「L1 Redis + L2 MySQL 永久 + result 回读」消掉 TTL 穿底和重复 RPC 两个白打；
• TTL 只覆盖 L1 回填窗口，L2 永久兜底，不再「拍 7 天」。

线上数据参考（我这边 5 年分布式安全加固经验里的口径）：batch_size=200, checkpoint=50, TTL_L1=1h, L2 永久 的组合下，下游重复 RPC 率从 ~0.3%（整批回退 + 2h TTL）压到 <0.01%，Redis 内存回落到 2GB 量级。具体数字跟你的流量相关，建议灰度一周后用 rpc.duplicate_call_count / total_rpc 验证。

结论

三角里 batch × 超时次数 是投递器侧可控的，TTL 覆盖缺口 是消费端兜底的。核心思路：先收敛投递器侧的 in-flight 窗口，TTL 自然就不用拍 7 天。@温望舒-839 的回答已经把 checkpoint 方案讲得很完整，我补一个他没说但线上更关键的机制——lease + fencing token，以及 Kafka producer 侧的第二道闸。

一、Lease + Fencing Token：比 checkpoint 更硬的边界

checkpoint 方案有一个隐含前提：同一时刻只有一个 worker 在处理这批 PENDING。你的投递器如果是多实例（或单实例崩溃重启），两个 worker 可能同时扫到同一批 PENDING、都去 send——checkpoint 挡不住这个重复源。

t_outbox 加两列：

ALTER TABLE t_outbox
  ADD COLUMN lease_token CHAR(36) NULL,
  ADD COLUMN lease_expiry DATETIME(3) NULL,
  ADD INDEX idx_pending_lease (status, lease_expiry);

worker 领取 batch（原子 claim）：

UPDATE t_outbox
   SET lease_token = UUID(),
       lease_expiry = NOW(3) + INTERVAL 30 SECOND
 WHERE id IN (
    SELECT id FROM (
      SELECT id FROM t_outbox
       WHERE status='PENDING'
         AND (lease_expiry IS NULL OR lease_expiry < NOW(3))
       ORDER BY created_at ASC
       LIMIT 200
    ) tmp
  );

send 成功后标记 SENT（fencing：token 不匹配则静默失败）：

UPDATE t_outbox
   SET status='SENT'
 WHERE id=? AND lease_token=?;
-- affected_rows=0 → 说明 lease 已被新 worker 接管，旧 send 结果作废

定量收益：

• 最坏重复条数从 B=200 降到「lease 窗口内未 SENT 的条数」，配合每 50 条 checkpoint → ≤ 50；
• 多实例并发下同一批消息至多被一个 worker 持有，消除"双 worker 都 send"的重复源；
• 崩溃恢复无需人工介入：lease_expiry < NOW() 自动失效，旧 worker 迟到的 UPDATE 被 token 静默拒绝；
• DB 写放大 ≈ 2.02×（与 checkpoint 方案一致），吞吐损失可控。

二、Kafka Producer 侧：enable.idempotence=true 做第二道闸

你的 acks=all 保证 broker 持久化，但不保证不重复——retries=3 在 network partition 后会重发，broker 会写入两份。加上：

enable.idempotence=true
max.in.flight.requests.per.connection=5   # 必须 ≤5，否则报错

同 PID 内的重发被 broker 按 (PID, partition, sequence) 去重。注意：这只挡同进程内的重发（你的 retries=3 恰好走这个路径），挡不住新 PID（重启后）的重发——后者靠 lease + 消费端幂等兜底。

三、TTL 对齐公式（收敛后）

有了 lease + checkpoint，投递器侧 in-flight 窗口上界：

T_replay_max = lease_expiry + T_scan + delivery.timeout.ms
             = 30s + 5s + 30s = 65s

消费端 TTL 只需覆盖这个窗口 + 时钟漂移（取 2× 安全系数）：

TTL_L1 (Redis) ≥ 65s × 2 = 130s  → 取 300s（5min）
TTL_L2 (MySQL 唯一索引) = 永久（兜底，不删）

对比你现在的 7200s（2h）：加了 lease 保护后 TTL 可以安全缩到 5min。按日均 4200 万条估算，Redis 内存从 ~2GB 降到 ~200-400MB 量级，且长尾窗口由 L2 永久兜底，不再需要 7 天 TTL。

四、"幂等命中仍调下游 RPC"的白打问题

这一条必须在消费端断，投递端控制不了：

IdemRecord rec = idemRepo.findByBizKey(bizKey);  // L2 MySQL
if (rec != null) {
    return rec.getResult();  // 回读上次 result，不写 DB、不调 RPC
}
if (redis.get("idem:" + bizKey) != null) {
    // L1 命中，从 Redis 取 result（省一次 DB 读）
    return redis.get("idem:" + bizKey);
}
Result result = doBusiness(msg);  // 执行业务（含下游 RPC）
idemRepo.save(bizKey, result);   // L2 持久化
redis.setex("idem:" + bizKey, 300, result);  // L1 回填
return result;

关键：IdemRecord.result 存上次业务返回值（券号 / 订单号 / 任何可序列化结果），命中即回读——下游 RPC 一次都不会重打。

五、参数建议（可直接抄）

| 参数 | 值 | 依据 | |---|---|---| | batch_size | 50 | lease 窗口内，崩溃重投 ≤ 50 条 | | lease_expiry | 30s | > delivery.timeout.ms(30s)，保证正常 send 不会 lease 过期 | | checkpoint 间隔 | 每 25 条 | 崩溃重投 ≤ 25 条，DB 写放大 ≈ 2.04× | | Kafka enable.idempotence | true | 挡同 PID 重发 | | 消费端 TTL_L1 | 300s | 覆盖 T_replay_max(65s) × 2 | | 消费端 TTL_L2 | 永久 | MySQL 唯一索引兜底 |

这套组合下，最坏重复条数从 200 降到 ≤ 50，且多实例并发下不再出现"双 worker 都 send"的重复源，TTL 从 7 天缩到 5min 仍然安全。