您现在的位置是：首页 > 文章详情

ZQPool 1.1 发布，连接池软件

日期：2023-02-10点击：286收藏

ZQPool 是一个可以替代 pgbouncer 的连接池软件，在1.1版本中主要做了一下改进：

之前的版本，前端连接过来的用户名和数据库名称必须与后端数据库中的完全一样，现在可以不一样。例如原先的版本如果使用scott用户连接ZQPool上的数据库maydb，那么连接到后端的真实数据库也是maydb，而新版本使用scott用户连接ZQPool上的数据库maydb，但实际上可能是使用yellow用户连接到后端的fourdb数据库上（具体看zqpool.conf中的配置）。
增加了后端连接的生命周期的功能，到达生命周期后，此后端连接会重建，以便避免数据库连接长时间不释放而可能的内存泄漏风险。
增加了管理端口，可以通过向ZQPool发送http请求动态改变一些配置。
优化了ZQPool配置
修复了一些Bug。

ZQPool主要解决 PostgreSQL 生态中流行的连接池软件 pgbouncer 软件的一些缺点。通常使用数据库连接池的主要目的有两个：

减少到数据库上的连接数。应用程序到连接池软件上有 M 个连接，这 M 个连接不是同时都繁忙的，这 M 个连接上同一个时刻发来的并发 SQL 可能只有 N 个（N 通常大大小于 M)，这样连接池软件只需要在后端数据库上建 N 个连接。就可以满足了要求。这个场景通常是 java 应用。我们可以想象一个场景：一个 java 应用可能部署在 200 台主机上，而每个主机上 java 应用自身会开启一个 java 连接池，这个 java 连接池假设开 20 个连接，这时到数据库上就有 200*20=4000 个连接，这些连接实际上多数时间都是空闲的，少数时间才是活跃的。 4000 个连接，PostgreSQL 数据库就需要启动 4000 个进程，太多连接会降低数据库的效率。
减少短连接应用花在新建数据库连接的时间。PostgreSQL 数据库对每一个连接需要 fork 出一个新的进程来提供服务，而每次 fork 一个进程是需要时间的。而连接池软件可以预先建好到数据库的连接，应用程序连接到连接池软件后，连接池软件可以从池中取一个已经建好的连接马上提供服务，这样就大大减少了新连接的时间。这个场景的典型应用是 php 应用。php 应用到数据库通常是短连接。

而 PostgreSQL 数据库中流行的 pgbouncer 通常解决不了上面的第一个问题（java 应用）：即减少到数据库上连接数的目的。要减少到数据库上的连接数，pgbouncer 连接池的模式只能配置成语句级或事务级，不能配置成会话级，因为 pgbouncer 在会话级下，前面来多少个连接，到数据库也必须建多少连接，根本起不到减少数据库连接的目的。当我们把 pgbouncer 配置成语句级或事务级时，java 应用连接 pgbouncer 会报错:

 org.postgresql.util.PSQLException: ERROR: prepared statement "S_1" already exists

这个原因是 jdbc 执行 SQL 是分两个步骤的:

先使用 Prepare 的 SQL，即：“prepare S_1 as select * from test01 where id=$1;”
然后再 “execute S1 (1);”

报错的原因为：

执行 “prepare S_1 as select * from test01 where id=$1;” 时，从连接池中取一个连接 A，执行后，就释放了此连接；
执行 “execute S_1 (1);”，再从连接池中获得一个连接，这时获得的连接可能已经不是之前的连接，这个新连接中没有 Prepare 语句 “S_1”，所以就报错了；
如果又来了另一个 SQL，可能从连接池中取到的还是之前的连接 A，然后再执行 “prepare S_1 as select * from test02 where id=$1;”，但这个 prepare SQL 的名字 S_1 已经被前面的 SQL 占用，这时就报错了。
当然 jdbc 的实际行为比上面描述的要复杂的多，但原理大致就是上面描述的这个过程。

而 ZQPool 通过跟踪一个连接上的 Prepare SQL 的名字，并替换成不重复的名字的方式解决了这个问题。

pgbouncer 还有一个缺点，处理 SQL 的转发只能用到 CPU 的一个核，即 pgbouncer 是单线程程序。对于高并发的情况下，超过单核的性能时，就会立即出现瓶颈。而 ZQPool 是使用 golang 的协程技术，可以利用了多核的性能，在一台 2 颗 Intel (R) Xeon (R) Silver 4210R CPU @ 2.40GHz 的物理机：

这是 pgbouncer 的测试情况：

 [postgres@csyun01 ~]$ pgbench -h 10.197.160.18 -p 6432 -Uu01  -S -P 2  -T 30 -c 32 pgbench (14.3) starting vacuum...end. progress: 2.0 s, 30407.5 tps, lat 1.050 ms stddev 0.180 progress: 4.0 s, 30108.6 tps, lat 1.062 ms stddev 0.182 progress: 6.0 s, 30231.5 tps, lat 1.058 ms stddev 0.179 progress: 8.0 s, 31157.9 tps, lat 1.026 ms stddev 0.176 progress: 10.0 s, 30491.7 tps, lat 1.049 ms stddev 0.178 progress: 12.0 s, 30463.0 tps, lat 1.050 ms stddev 0.180 progress: 14.0 s, 30366.2 tps, lat 1.053 ms stddev 0.179 progress: 16.0 s, 30177.5 tps, lat 1.060 ms stddev 0.180 progress: 18.0 s, 30067.1 tps, lat 1.064 ms stddev 0.181 progress: 20.0 s, 30420.1 tps, lat 1.051 ms stddev 0.177 ... ... ...

这是使用 ZQPool 测试的情况：

 [postgres@csyun01 ~]$ pgbench -h 10.197.160.18 -p 5436 -Uu01  -S -P 2  -T 30 -c 32 Password: pgbench (14.3, server 10.5) starting vacuum...end. progress: 2.0 s, 111134.7 tps, lat 0.213 ms stddev 0.058 progress: 4.0 s, 112688.1 tps, lat 0.209 ms stddev 0.058 progress: 6.0 s, 114570.8 tps, lat 0.207 ms stddev 0.054 progress: 8.0 s, 107305.3 tps, lat 0.216 ms stddev 0.066 progress: 10.0 s, 108680.1 tps, lat 0.215 ms stddev 0.063 progress: 12.0 s, 108867.6 tps, lat 0.214 ms stddev 0.064 ... ... ...