如何评估长事务风险以减少fast模式的影响

一、为什么要专门“评估”长事务
在 fast 模式关闭时，postmaster 向所有子进程发送 SIGTERM，长事务会立即进入回滚路径。回滚必须写 WAL、刷脏页、释放锁、更新 clog，这些动作不仅占用 I/O 带宽，还会把 BufferPool 里的热数据踢出，导致重启后缓存命中率骤降。因此，**评估长事务风险=提前量化关闭时的回滚成本**，从而把 fast 模式的“不可控抖动”变成“可预期窗口”。

二、风险模型：把“长事务”拆成四个维度
1. 活跃时间（Duration）：事务已开启多久。
2. 修改量（Dirty Pages）：事务已产生多少脏页和 WAL。
3. 锁数量（Lock Set）：事务持有什么级别的锁，是否阻塞别人。
4. 会话类型（Connection Type）：普通业务连接、后台批处理、逻辑复制槽。

把这四个维度映射为两项可观测指标：
- 回滚耗时 Trollback ≈ Dirty Pages ÷ Disk Bandwidth × 2（经验系数）
- 业务中断 Toutage = Trollback + Tconnect（连接池重建时间）

三、事前评估：七步 SOP
1. 快照当前会话
```
SELECT pid,usename,application_name,state,query_start,
pg_xact_start_duration(pid) AS duration,
pg_blocking_pids(pid) AS lockers
FROM pg_stat_activity
WHERE state <> 'idle';
```
2. 计算脏页
```
SELECT pid,
pg_total_relation_size(relid)/8192 AS pages_total,
pg_stat_get_dirty_pages(pid) AS pages_dirty
FROM pg_locks l
JOIN pg_class c ON l.relation=c.oid
WHERE l.locktype='relation' AND l.mode='RowExclusiveLock';
```
3. 估算 WAL 量
```
SELECT pid,
pg_wal_lsn_diff(pg_current_wal_insert_lsn(),xact_start_lsn)) AS wal_bytes
FROM pg_stat_activity
WHERE state='idle in transaction';
```
4. 聚合风险分数
```
Risk = Σ(duration * pages_dirty * (1+ lock_count))
```
按业务库设定阈值：
- Risk < 1000：低风险，可立即 fast；
- 1000–5000：中风险，需先 kill 或等待；
- >5000：高风险，建议使用 smart。

5. 可视化报警
把上述 SQL 包装成 Prometheus exporter：
```
# HELP pg_long_transaction_risk_score
pg_long_transaction_risk_score{usename="etl"} 7123
```
Grafana 面板阈值红线 5000，一目了然。

6. 审计长事务来源
- 开启 `log_min_duration_statement = 30s` + `log_checkpoints = on`，通过 ELK 分析哪些模块/用户经常产生长事务。
- 使用 `auto_explain` 把超过 30 s 的语句自动抓执行计划，定位慢 SQL。

7. 演练回滚耗时
在准生产库执行：
```
-- 制造 1 GB 脏页的长事务
BEGIN;
UPDATE big_table SET col = col + 1;
-- 不提交
```
然后 `time pg_ctl stop -m fast`，记录实际回滚耗时，与模型 Trollback 对比，修正经验系数。

四、事中干预：把“长事务”变“短事务”
1. 强制取消
```
SELECT pg_cancel_backend(pid), pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state='idle in transaction' AND duration > 10 * 60 * 1000;
```
2. 提前拆分大事务
对 ETL 任务：
- 把单条 `UPDATE … WHERE filter` 拆成批量、分片；
- 使用 `COPY FREEZE` 或 `CREATE TABLE AS` 代替大更新，减少回滚量。
3. 连接池限速
在 pgbouncer 配置：
```
max_client_conn = 200
pool_mode = transaction
server_reset_query = DISCARD ALL
```
把长事务隔离到独立 pool，关闭时仅重启该 pool，避免全局回滚。

五、事后治理：把评估结果固化到流程
1. 上线门禁
CI/CD 流水线增加 SQL Review：
- 任何单条 DML 影响行数 > 100 万，必须走 DBA 审核；
- 新增索引、VACUUM FULL 必须在窗口期执行。
2. 监控闭环
- 每周导出 `pg_stat_statements`，按 `total_exec_time` 排序，Top10 长事务 SQL 强制重构；
- 长事务风险分数纳入 SLO：若周均值超过 2000，触发复盘。
3. 自动自愈
使用 Patroni callback：
```
on_stop:
- /usr/local/bin/long_tx_guard.sh
```
脚本发现 Risk>5000 时自动切换为 smart 模式，并钉钉告警。

六、案例：某头部电商大促演练
背景：双 11 前压测 10 万 QPS，库内 3 TB，单事务最大 120 GB。
步骤：
1. 评估脚本跑完 Risk=8000，判定高风险；
2. 将 120 GB 大事务拆 12 份，每份 10 GB，Risk 降到 900；
3. 演练 fast 关闭，回滚耗时从预估 180 s 降到 18 s，连接重建 5 s，整体窗口从 3 分钟缩短到 23 秒；
4. 大促当天实际执行 4 次滚动发布，业务零中断。

七、总结
评估长事务风险的核心是**把不可见的回滚成本量化成可观测指标**，并通过“事前发现-事中干预-事后治理”形成闭环。只要遵循本文七步 SOP，就能把 fast 模式的性能抖动压缩到秒级，真正做到“随时可关，关后秒启”。