PostgreSQL中常用的几种连接池总结及更新
前言
PostgreSQL的多进程结构，使得在支持大规模连接的时候，服务器端显得比较吃亏。一般上了1000个连接以上的时候，系统就会受到很大影响。这个时候，使用连接池，优势就会突显出来了。
在云环境下，一个JAVA应用服务，可能会启动成多个进程实例，而每个进程实例又依赖于java的数据库连接池，不管是Ｈikari，还是阿里的druid，还是其他的一些所谓的高性能连接池，因为都是基于连接会话的，最终并不能对总的连接进程数有多大缓解。
在唐成老师的ZQPool 1.3 发布一文中，甚至对此都有吐糟。
而使用第三方连接池的一个很重要的目的就是：（引自上边的文章）
减少短连接应用花在新建数据库连接的时间。PostgreSQL数据库对每一个连接需要fork出一个新的进程来提供服务，而每次fork一个进程是需要时间的。而连接池软件可以预先建好到数据库的连接，应用程序连接到连接池软件后，连接池软件可以从池中取一个已经建好的连接马上提供服务，这样就大大减少了新连接的时间。这个场景的典型应用是php应用。php应用到数据库通常是短连接。
总进程数不能缓解的问题，ZQPool彻底解决了。不能不说是一件快事。
分析与总结
既然是好消息连连，我们就一个个总结:
1、Odyssey连接池
详细信息见我前段时间总结出来的：
高可用: 体验使用Odyssey连接池(一)
高可用: 体验使用Odyssey连接池(二)
总的印象是，系统资源开销小。但是目前似乎仍未解决总连接数受制于总会话数的问题。同时，用户密码验证，最多只能用到MD5。与里边的开发人员沟通过，说scram-sha-256的完全支持也应该是可以的，需要再重新验证和fix。
2、pgbouncer
我要说的是，最新版本的pgbouncer开始支持statement、transaction级别的真正复用了。
以前在使用这两级复用的时候，经常出下边的错：
org.postgresql.util.PSQLException: ERROR: prepared statement "S_1" already exists
解决了这些问题，那么就可以更加稳健的使用statement level的连接池了。
PgBouncer 1.21.0 （http://www.pgbouncer.org/2023/10/pgbouncer-1-21-0）在10月16号的时候宣布得以解决。
Oct 16, 2023 - PgBouncer 1.21.0
PgBouncer 1.21.0 has been released. This release adds one of PgBouncer its most requested features: Support for named prepared statements! See the docs on
max_prepared_statementsfor details on how the feature works, its limitations, and how to tune the value of themax_prepared_statementssetting.Apart from prepared statement support this release also includes various other improvements, such as much more secure default TLS settings and changes required for FIPS compliance. And it also fixes various bugs and crashes.
See the full details in the changelog.
Download here: pgbouncer-1.21.0.tar.gz (sha256)
3、国产的ZQPool
看了zqpool的介绍，使用方法是真的简单明了。
具体可以参照 ：ZQPool 1.3 发布：https://mp.weixin.qq.com/s/OVZoVyP1MWqi1MK37u2TDQ
https://gitee.com/csudata/zqpool/releases/tag/1.3
zqpool#安装教程： https://gitee.com/iihero/zqpool#%E5%AE%89%E8%A3%85%E6%95%99%E7%A8%8B
使用的是GO语言开发。编译安装也简单。直接make。也提供二进制包下载。
ZQPool简单使用说明
配置zqpool.conf文件，各个配置项说明如下：
-
listen_port = 5436 ： 设置zqpool的监听端口
-
listen_addr = * : 设置zqpool的监听IP，设置为*，表示在本地的所有IP地址上监听
-
mgr_port = 9380 : 管理端口
-
mgr_addr = * : 管理端口监听的地址
各个连接池的配置：
-
pool.1.fe_max_conns = 3000
-
pool.1.fe_user=mydb
-
pool.1.fe_passwd=test12
-
pool.1.fe_dbname=mydb2
-
pool.1.be_user=mydbabc
-
pool.1.be_passwd=test12
-
pool.1.be_dbname=mydb123
-
pool.1.be_conns = 10
-
pool.1.be_ipport=172.22.224.10:5432,172.22.224.10:5411
-
pool.1.be_conn_life_time=60 # 指定连接的life_time，当连接超过这个时间后，会被销毁重连，主要是为了防止内存泄漏
fe_指的就是frontend, 就是前端访问zqpool的服务端口等信息。非常明了。
它似乎是兼顾考虑到了目前各种轻量级连接池的优点。因为它解决了上边接到的Prepare语句不能复用的问题。同时开销也非常小。能支持更大的并发量。相信它有很好的使用机会。
再看了看它的license:
木兰公共许可证, 第2版
木兰公共许可证， 第2版
2021年5月 http://license.coscl.org.cn/MulanPubL-2.0
看不出使用它有多大的风险。
同时也说说它安全性上的特点：
上边的配置文件里头有明文的密码。我没试过，不加入那些密码项，是不是也能工作？还有它目前只支持password_encryption=md5的用户连接。与Odyssey一样。如果作为一个不断增强的软件而言，相信以后它会在这方面会做一些加强性的工作。那样才能让用户更加放心的使用。
对这三种连接池，推荐使用：pgbouncer -> zqpool->Odyssey
甚至可以是哪个熟练有把握，就用哪个。相信功能也都会越来越健壮。