2. PostgreSQL 连接原理：客户端-服务器通信模型与连接开销分析

在深入中间件连接池配置之前，必须透彻理解 PostgreSQL 原生的连接机制。PostgreSQL 采用经典的进程-连接模型（Fork-on-Connect），每个客户端连接对应一个独立的服务器进程（Backend Process）。这种架构在保证隔离性的同时，也带来了显著的连接建立与销毁开销。

2.1 客户端-服务器通信模型

PostgreSQL 的通信模型基于 TCP/IP 或 Unix Socket，采用半双工的消息流协议。整个连接生命周期分为三个阶段：建立（Startup）、查询（Query）、销毁（Termination）。

2.2 连接建立过程详解

一个 PostgreSQL 连接的建立并非简单的 TCP 握手，它包含多个协议交互步骤。以下是完整的连接建立流程：

1. TCP 三次握手：客户端与 Postmaster 进程建立 TCP 连接。
2. SSL/TLS 协商（可选）：如果配置了 SSL，双方协商加密参数。
3. 启动包发送：客户端发送 StartupMessage，包含数据库名、用户名、协议版本等。
4. 认证交互：服务器根据 pg_hba.conf 规则选择认证方式（密码、SCRAM-SHA-256、GSSAPI 等），可能包含多次消息往返。
5. 后端进程 Fork：Postmaster 通过 fork() 创建子进程（Backend Process），子进程继承父进程的内存空间。
6. 参数同步：子进程加载会话参数（search_path、timezone 等），发送 ReadyForQuery 表示连接就绪。

2.3 连接建立与销毁开销量化分析

为了直观理解连接池的必要性，以下表格对比了连接建立、空闲查询和连接销毁的典型开销：

2.4 连接销毁过程与资源回收

连接销毁（Termination）同样涉及多个步骤，并非简单的 TCP 关闭：

• 客户端发起关闭：发送 Terminate 消息（X 包）。
• 后端进程清理：回滚未提交事务、释放锁、关闭游标、清理临时表。
• 共享内存资源释放：释放进程占用的共享内存槽位、信号量、文件描述符。
• 进程退出：子进程调用 exit()，向 Postmaster 发送 SIGCHLD 信号。
• Postmaster 回收：Postmaster 调用 waitpid() 回收子进程资源，更新进程列表。

频繁的连接销毁会导致 TCP TIME_WAIT 状态堆积，以及操作系统级别的进程表膨胀，进一步加剧资源消耗。

2.5 连接池为何成为必需品

基于上述分析，可以总结出 PostgreSQL 原生连接模型的三个核心痛点：

• 高延迟：每次连接建立需要 2-30 ms，对于毫秒级响应的应用来说不可接受。
• 高资源消耗：每个连接占用 5-10 MB 内存，1000 个连接即消耗 5-10 GB 内存。
• 低扩展性：进程模型导致连接数受限于操作系统进程表大小和 CPU 调度能力。