PgBouncer 连接池模式对比（transaction vs session）+ 高并发写入压测脚本 + 选型决策树

背景

我们团队在跑 10 个微服务写入同一张 5000 万行订单表（PostgreSQL 16），连接池用 HikariCP（max=100/服务），高峰期 500 个活跃连接打满 PG 的 max_connections，WAL 写放大严重。计划引入 PgBouncer 做中间层，但 transaction pooling 和 session pooling 在高并发写入场景下的吞吐差异、锁争用表现、事务隔离级别兼容性 我还没有拿到一组可信的量化数据。

最终要什么

一份可复现的基准对比报告 + 压测脚本 + 一张「什么场景选什么模式」的决策树，让我能在下周架构评审时直接拿数据拍板。

输入与上下文

• 数据库：PostgreSQL 16.3（Docker 镜像 postgres:16.3），单实例，4C/8G
• 表结构：orders（id BIGSERIAL PK, user_id BIGINT, amount NUMERIC(12,2), status SMALLINT, created_at TIMESTAMPTZ），5000 万行，索引：PK + (user_id, created_at)
• 写入负载：100 并发连接，每事务 INSERT 1 行 + UPDATE 1 行（模拟订单创建 + 状态流转），持续 5 分钟
• PgBouncer 版本：1.21+
• 对比维度（至少覆盖）：
  1. 无 PgBouncer（直连）
  2. PgBouncer transaction pooling（default_pool_size=50）
  3. PgBouncer session pooling（default_pool_size=100）
  4. 每种模式下分别测 p95/p99 延迟、TPS、错误率
  5. 额外场景：开启 idle_in_transaction_session_timeout=30s 后 transaction 模式的表现
• 压测工具：推荐 pgbench 自定义脚本或 psql-bench，须可一键复现（提供 Dockerfile + run.sh）

交付格式

1. Markdown 报告（≥2000 字）：含环境说明、测试方法、各组数据表格、p95/p99 对比图（ASCII 或 SVG 均可）、锁争用分析（pg_stat_activity 采样）、结论
2. 压测脚本包：Dockerfile + docker-compose.yml + run.sh + 自定义 pgbench SQL，docker compose up 即可跑
3. 选型决策树：一张 Mermaid 流程图，节点为「事务是否含 SET / 是否用 LISTEN-NOTIFY / 并发量级 / 是否需要会话级 prepared statement」等判断条件，叶节点为推荐模式 + 关键参数

注意事项

• 数据必须真实可复现，不接受「根据经验估计」
• 报告里须标注 PG 版本、PgBouncer 版本、Docker 版本、宿主机 CPU/内存
• 如发现 session 模式在某些 SQL 模式下完全不可用（如 advisory lock），须单独列出并给替代方案