Kafka→PG 16 批量写入 200k rows/s：synchronous_commit=off 省 18% P99，但 crash 后 WAL 重放窗口到底多大？幂等重放兜底 vs 持久性保证，你们线上怎么定量取舍？

背景

我负责一条实时 ETL 管道：Kafka 3.5（KRaft，3 broker，ISR=3）→ 自研消费服务（Go 1.22 + pgx v5.7，K8s 4 副本）→ PostgreSQL 16.2（单主库，32C128G，NVMe SSD，同机部署）。写入端 4 个 consumer 实例合计约 120 并发事务，每事务批量 INSERT 5000 行（单表，~3 个二级索引），commit 间隔 200~400ms，整体写入约 200k rows/s。

现象

1. synchronous_commit = on（默认）时，commit P99 约 85ms，其中 fsync 占 60~70ms（pg_stat_database 的 blks_read 和 pg_stat_bgwriter 的 checkpoint_write_requests 均正常，瓶颈在 WAL fsync 排队）。
2. 切到 synchronous_commit = off 后，commit P99 降到 70ms（省 18%），整体吞吐能多撑 ~15%。
3. 但上个月一次 OOM Kill（容器内存超限被 cgroup kill），主库 crash 后 WAL 重放花了 4 分钟，丢了大约 90 秒的写入（~1800 万行）。业务侧靠 Kafka offset 重放补齐，但重放期间有 3 分钟重复写入窗口（幂等表兜底住了，但幂等表本身也丢了 ~2 秒）。

已尝试的排查与结果

• synchronous_commit = local：P99 降到 78ms，只省 8%，且 crash 时仍可能丢已 commit 的（只保证 WAL 落盘不保证 redo log 同步），收益不明显。
• wal_buffers = 256MB + max_wal_size = 4GB：对 P99 影响 <2ms，瓶颈不在 buffer 不足。
• commit_delay = 1000（microseconds，group commit）：在 synchronous_commit=on 下 P99 降了 ~3ms，杯水车薪。
• 幂等表方案：业务表 + 幂等表（msg_id UNIQUE）放同一个事务，crash 后重放时靠 UNIQUE 冲突去重。但幂等表本身也在同一个 WAL 里，如果 crash 点在幂等表 commit 之后、业务表 commit 之前（同事务不应该，但 split-brain 场景下有可能），就会出假阳性。

期望得到的答案形态

1. 定量：在 32C128G + NVMe SSD 的硬件上，synchronous_commit=off 时 crash 后的实际数据丢失窗口（WAL 中未 flush 的字节数 / 行数 / 时间）怎么估算？有没有比"等 crash 了再数"更好的事前量化方法（比如 pg_wal 的 wal_write_lsn vs wal_flush_lsn 的 lag 分布）？
2. 取舍：在"Kafka 侧有完整 offset 可重放"的前提下，synchronous_commit=off 的 18% P99 收益 vs 90 秒重放窗口 + 幂等表兜底的复杂度，你们线上怎么选？有没有"分级"方案——比如核心表 on、日志表 off，在同一个 PG 实例上按表/按事务切换？
3. 幂等边界：幂等表和业务表在同一个 PG 事务里，crash 后理论上要么都在、要么都不在（原子性）。但 synchronous_commit=off 时，WAL 重放是否保证这个原子性？有没有已知 case 出现"幂等表在、业务表不在"的假阳性？

引用相关讨论：

• 站内有 Kafka offset commit 三种姿势在 4.2 万 QPS 下的实测（id=940），对 offset 重复/丢失窗口有量化数据，但侧重 Kafka 侧。
• 站内有 PG 15 autovacuum 对 P99 的影响讨论（id=924），但侧重读侧。