开头还是介绍一下群，如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，在新加的朋友会分到2群。

最近得到与PGBOUNCER的一个问题，问题大体上是这样描述的，一台POSTGRESQL的服务器，2000个max connection ，同时安装了4个 pgbouncer 在不同的机器上，来连接POSTGRESQL 数据库，最近出现了问题，连接数据库服务器超时的问题。

当被问及这个问题的时候，我其实也是比较惊讶，很少有听说这样使用的方式。一般PGBOUNCER 是安装在数据库上的，也就是与数据库成为一体的模式来进行使用的。为什么使用PGBOUNCER 主要的原因在于基于PG的原理，PG 更愿意去使用通过更少的连接数，来服务与更多的使用者，所以PGBOUNCER 实际上是一个 分时复用的核心概念的产品，也就是对于连接进行分时复用，所以这里PGBOUNCER 的功能是十分的简单，好处也有安装方便并且基本上比较稳定。

同时基于PGBOUNCER 的配置，也比较简单和简洁。配置主要分为几个部分

1  pgbouncer 配置文件内容

2  pgbouncer 的内部界面与使用

3  监控与配置刷新与使用

这里简单的说说pgbouncer 的配置文件的内容部分，配置的大块主要由databases , users , pgboucner 几个部分组成

1  databases 部分主要，主要以连接为主，pgboucner的连接主要包括连接符号，主机地址 端口号  数据库名字 以及连接中的测试query部分，database 这部分实际上是dbname = connection string ,来进行PG数据库与pgbouncer 之间进行对接的在PGBOUNCER 中显示的数据库。所以这个名字很可能与实际的你的物理数据库的数据库名字不一样，或者一个PGBOUNCER 可以连接多个物理的数据库，通过PGBOUNCER 作为一个数据安全的连接的屏蔽器使用。

这里有一个问题，经常被问题，就是如何登陆到PGBOUNCER 的界面中，这里很简单，你在登陆的时候，需要设置几个点

1  admin users 需要进行设置，这里的设置的账号就是登陆pgbouncer的账号名字，密码不用设置

2  登陆的时候，需要指定登陆的数据库是 pgbouncer 而不是别的，

3  在userlist.txt中设置 匹配admin users  的账号和密码，不要和登录数据库的账号重了。

做完这三点，那么就就可以登陆到pgbouncer 的系统中。

这部分在很多的文字中都模模糊糊，写的不清晰。为什么非要登陆到pgbouncer 中，主要的原因是，因为配置更改后，要动态加载到内存中，reload命令需要在内部进行运行。

下面这个例子是通过pgbouncer 连接到 192.168.198.100 的数据库中的数据库postgres的连接的例子，这样设置后就可以通过databases 模块与我们的数据库相连接。 

pgbouncer 

[databases]

postgres = host=192.168.198.100 port=5432 dbname=postgres connect_query='select 1'

[users]

[pgbouncer]

主要的PGBOUNCER 对于postgresql有利的部分就是 pool mode

在pool mode中重要的部分就是客户与服务器的连接模式的部分

1  session

2  transaction

3  statement

这三种的应用模式，中熟悉连接模式的同学都知道 transaction的模式是最常用的，而 session 的模式是最安全和妥当的，statement 没有什么应用去选择。实际上可以选择的部分只有两个 transaction  and  session.而在之前的测试中 session 本身的提高连接复用的可能性不高，同时程序的连接池也具有这个功能，所以，一般来说transaction 是 pgbouncer的最适合的应用模式。

实际上部署PGBOUNCER 有一个问题所在，就是如何进行HA， 也就是说PGBOUNCER 本身是和数据库一起绑定部署，还是分离部署的方式。

这点对于PGBOUNCER是一个部署的决定。实际上这个与本身的数据库的数量和部署的有关。

1   如果你的项目中的数据库很多，那么分离的部署方式是适合你的，这样有利于扩展数据库，和扩展连接代理。

2  部署多个 pgbouncer 同时通过应用的DNS 的轮训方式来进行高可用的切换放方式，而这样的方式的问题点，在于如果你的PGBOUNCER失败后，如何进行拉起的问题，或者通过DNS 来屏蔽出现故障的节点的部分。

3  通过K8S 来进行大量的pgbouncer 的部署，通过批量部署和借用 K8S 的管理功能更来将pgbouncer 高可用的工作进行接管。

4   直接将pgbouncer  与应用程序端进行绑定，也就是一个应用程序端一个pgbouncer 如果应用程序端失效或pgbouncer失效会很快被发现通过自动拉起的监控来进行pgbouncer的高可用设计。

PGBOUNCER本身承接了连接池维持的工作，如果pgbouncer断掉会影响现有的连接，所以应用程序必须有相关的功能针对PGBOUNCER失败后的重连机制和相关的工作机制。

PGBOUNCER 本身并不是DBA 自己的事情，是一个综合需要考虑的问题，高可用的部分也不是DBA 自己的事情，是一个与应用架构需要进行协商后，进行设定的工作，每种不同的设定本身都具有自己的特性，如频繁变动配置的PGCBOUNER 建议集中部署， 而数据量较少的情况下，PGBOUCNER和数据库本身来进行部署，更有效率。

PGBOUCNER的部署本身，和整体的公司的PG的数量，逻辑库的数量，以及公司管理访问数据库的规范等等都有关，如何切合实际的部署pgboucner是一个需要综合考虑的问题。