PG 15 高并发写入下 autovacuum 导致读 P99 从 5ms 飙到 200ms：参数怎么调、隔离方案怎么选

【背景】 我在做一条金融级实时风控事件流管道：Kafka → 自研消费服务（JDK 17 + Spring Boot 3.2 + HikariCP 5.1）→ PostgreSQL 15（单主库，32C128G，NVMe SSD）。写入端 16 个 consumer 实例合计约 200 并发 INSERT + UPDATE 事务，平均事务涉及 3~5 张表，单事务 2~4 条 SQL。读端是独立的 8 个查询实例，主要走 3 张事实表的点查 + 范围查，QPS 约 3000。

【现象】

• 稳态下读 P50 ≈ 3ms、P99 ≈ 5ms，完全达标。
• 每隔 8~15 分钟，P99 突然飙到 150~300ms，持续 3~8s 后回落，频率与写入高峰期正相关。
• pg_stat_activity 里看到 autovacuum worker 在跑 target 表（约 2.3 亿行），同时 read-only 事务的 wait event 集中在 LWLock/BufferMapping 和 Lock/unlogged relations。
• pg_stat_user_tables 显示该表 last_autovacuum 间隔 ≈ 10 min，n_dead_tup 峰值 ≈ 420 万。
• 开启 track_io_timing 后，autovacuum 期间 read 的 io_read 延迟从 0.1ms 涨到 1.2ms。

【已尝试的排查与结果】

1. 把 autovacuum_vacuum_cost_limit 从默认 200 调到 400 → 抖动窗口从 ~8s 缩到 ~5s，但没消除。
2. 把 vacuum_cost_delay 从 0 调到 2ms → 抖动消失，但 dead tuples 堆积更严重（峰值 900 万），后续 ANALYZE 又变慢。
3. 试过 pg_repack 在线 rebuild → 离线窗口可以做，但治标不治本，dead tuple 还会再涨回来。
4. 考虑过把读端切到 Citus 分片 → 架构改动太大，暂不考虑。
5. 也看了 pg_stat_activity 里有没有 long-running transaction 持锁 → 没有，排除了长事务阻塞。

【期望得到的答案形态】

1. 针对「200 并发写 + 3000 读 QPS + 单表 2.3 亿行」这个量级，autovacuum 的 cost_limit / cost_delay / max_workers / schedule_delay 四件套具体怎么配？希望给出一组可落地的参数组合和背后的调参逻辑（为什么是这个值）。
2. 如果 autovacuum 调参到极限仍然不够（dead tuple 产生速率 > VACUUM 回收速率），有没有比 pg_repack 更轻量的隔离方案？比如读写分离到物理复制副本 + 副本上关 autovacuum 是否可行？有什么坑？
3. 有没有社区里验证过的「写入侧减少 dead tuple 产生」的工程实践？比如批量合并写、减少 UPDATE 频率、用 INSERT ON CONFLICT 替代 SELECT+UPDATE 等，最好带上数据对比。