📚 课程目录第2章 PostgreSQL 基础回顾

2. PostgreSQL 基础回顾：连接模型、进程架构、共享内存与 WAL 机制

在深入 Go 连接池调优之前，必须理解 PostgreSQL 的底层运行模型。PG 采用 多进程 + 共享内存 架构，与 MySQL 的线程模型有本质区别。本节将拆解连接模型、进程架构、共享内存结构以及 WAL 机制，为后续的连接池参数计算和慢查询分析打下基础。

2.1 连接模型：进程 per-connection

PostgreSQL 使用 一个客户端连接对应一个后端进程 的模型。当客户端发起连接请求时，主进程 postmaster 会 fork 出一个新的子进程（postgres）专门为该连接服务。这个进程会一直存活，直到客户端断开连接。

  关键影响： 每个连接都会消耗约 5–10 MB 的共享内存和进程私有内存。连接数越多，上下文切换和内存开销越大。Go 应用如果使用短连接或大量空闲连接，会迅速耗尽系统资源。

特性	PostgreSQL	MySQL（线程模型）
进程/线程	多进程	多线程
连接开销	高（每个连接一个进程）	低（共享线程池）
隔离性	强（进程级隔离）	中等（线程共享地址空间）
连接数上限	通常 200–500（受内存限制）	可上千（受线程栈限制）

Go 连接池启示： 不要为每个请求创建新连接。使用连接池复用连接，将活跃连接数控制在 max_connections 的 50%–70% 以内，避免触发 PG 的 OOM killer。

2.2 进程架构详解

PG 的进程架构分为三个层次：

Postmaster（主守护进程）： 监听端口、接受连接、fork 子进程、处理信号。
Backend（后端进程）： 每个客户端连接对应一个，负责执行 SQL、管理事务、访问缓冲区。
Auxiliary（辅助进程）： 包括 WAL 写入器、检查点进程、统计收集器、自动清理进程等。

常见误区： 不要将 PG 的 max_connections 设置得过高（如 1000+）。每个后端进程都会占用共享内存中的锁、缓冲区描述符等资源。过高的连接数会导致检查点变慢、WAL 膨胀，甚至触发 OOM。建议结合连接池将活跃连接数控制在 200 以内。

2.3 共享内存结构

PG 的共享内存是多个后端进程之间交换数据和同步状态的核心区域。主要包含以下组件：

组件	用途	配置参数
共享缓冲区	缓存数据页，减少磁盘 I/O	`shared_buffers`
WAL 缓冲区	暂存 WAL 记录，批量刷盘	`wal_buffers`
锁空间	管理表级锁、行级锁、轻量锁	`max_locks_per_transaction`
进程数组	记录所有后端进程的状态	`max_connections`
CLOG	事务提交日志，判断事务可见性	固定大小

  调优要点： shared_buffers 通常设置为物理内存的 15%–25%。如果设置过大，会导致操作系统缓存与 PG 缓存竞争，反而降低性能。对于 Go 应用，如果查询模式以索引扫描为主，适当增大 shared_buffers 可以减少随机 I/O。

2.4 WAL 机制：预写日志

WAL（Write-Ahead Logging）是 PG 保证数据持久性和崩溃恢复的核心机制。其基本原则是：在数据页写入磁盘之前，必须先写入 WAL 日志。

WAL 的工作流程如下：

事务修改数据页时，先将修改记录写入 WAL 缓冲区。
事务提交时，WAL 缓冲区内容刷入 WAL 段文件（pg_wal 目录）。
后台进程（WAL Writer）定期将 WAL 缓冲区刷盘。
检查点进程将脏页写入数据文件，并更新检查点位置。

性能影响： WAL 写入是事务提交的关键路径。如果 wal_buffers 太小，或者磁盘 I/O 延迟高（如使用 HDD），事务提交的延迟会显著增加。对于 Go 应用中的高并发写入场景，建议：
• 将 wal_buffers 设置为 16MB–64MB
• 使用 SSD 存储 WAL 段
• 考虑 synchronous_commit = off（允许一定数据丢失风险时）

2.5 连接模型与 Go 连接池的映射

理解 PG 的进程架构后，可以得出以下 Go 连接池设计原则：

连接复用： 每个 PG 后端进程对应一个 TCP 连接。Go 连接池应尽量复用连接，避免频繁创建和销毁进程。
连接数控制： 连接池的最大连接数应小于 PG 的 max_connections，并预留 10%–20% 给管理工具和辅助进程。
空闲连接回收： 设置合理的 MaxIdleTime，避免大量空闲连接占用 PG 进程资源。
事务管理： 长事务会阻塞 WAL 清理和 autovacuum，连接池应避免在连接上长时间持有事务。

避坑指南： 不要使用 SELECT 1 作为连接池的健康检查。PG 的进程模型下，即使连接正常，也可能因为事务 ID 回卷等问题导致性能下降。建议使用 SELECT pg_is_in_recovery() 或 SELECT 1 FROM pg_stat_activity LIMIT 1 进行轻量级检查。