Pgbouncer最佳实践 之 池模式篇

了解更多Greenplum技术干货，欢迎访问Greenplum中文社区网站

《Pgbouncer最佳实践》系列已经连载到了第三篇，第一篇 概念篇 介绍了数据库连接池在Pgbouncer中的三种方式。为什么使用连接池，使用与不使用之间的性能差异，以及连接池模式的工作流程、细节及一些注意事项等内容。第二篇 性能提升篇介绍了Pgbouncer带来的性能提升的相关测试。

第三篇，本文将详细介绍事务池、会话池和语句池。

Pgbouncer具有三种可用的池模式：事务模式，会话模式和语句模式。在Greenplum中，gpboucner的池模式和pgbouncer相同。

事务连接池

数据库客户端很少在不间断的情况下执行连续的事务。而是通常在事务之间执行非数据库工作。这意味着服务器连接在等待新工作到达时会花费大量时间空闲。

事务池模式试图减少服务器连接的空闲时间，如下所示：

• 池程序在开始事务时将服务器连接分配给客户端。
• 客户端的事务完成后，池程序将释放连接分配。

注意事项：

• 如果客户端运行多个事务，则每个事务可以在不同的服务器连接上执行。
• 单个服务器连接可以在其生命周期内运行由不同客户端发出的事务。

图 6 事务连接池

与服务器所允许的连接相比，允许活动客户端的数量要多得多。尽管取决于给定的工作负载，但经常会看到10倍或更多的活动客户端连接与服务器连接比率。

这确实带来了一个重要的警告：客户端不再期望对数据库会话状态所做的更改在同一客户端进行的连续事务中继续存在，因为这些事务可能在不同的服务器连接上运行。此外，如果客户端进行会话状态更改，它们可能并且很可能会影响其他客户端。

以下是一些使用上面的事务池示例：

• 如果客户端1在T1中的第一个服务器连接上将会话设置为只读，而客户端2的T3是写事务，则T3将失败，因为它在现在的只读服务器连接上运行。
• 如果客户端1运行PREPARE a1 AS ...在T1上运行EXECUTE a1 ...，在T2上，则T2将失败，因为预编译语句对于运行T1的服务器连接是本地的。
• 如果客户端2在T3中创建了一个临时表并尝试在T4中使用它，则T4将失败，因为该临时表对于运行T3的服务器连接是本地的

有关使用事务池时不支持的会话状态功能和操作的完整列表，请参见PgBouncer的列表。

会话连接池

分配给客户端的服务器连接在客户端连接的整个生命周期内持续。这看起来好像根本不使用连接池一样，但是有一个重要的区别：当分配的客户端断开连接时，服务器连接不会被破坏。当客户端断开连接时，池管理器将：

• 清除客户端所做的任何会话状态更改。
• 将服务器连接返回到池中，以供其他客户端使用。

图 7 会话连接池

语句连接池

在此，服务器连接分配仅在单个语句的持续时间内持续。这具有与事务池模式相同的会话状态限制，同时还破坏了事务语义。

图 8 语句连接池

这使得所有客户端连接的行为就像在“自动提交”模式下一样。如果客户端尝试开始多语句事务，则合并程序将返回错误。

表 3 连接池模式对比

从上述对比情况来看，在连接池的选择上，需要依据业务环境特点来进行选择，默认情况下推荐使用事务连接池，它兼顾了执行事务的特性，尤其多语句的支持，并且不会像会话连接池那样，尝尝处于等待状态。当然事务模式并不支持预编译语句。而根据具体业务场景的特殊需要，有些时候需要客户端与服务器端保持连接，或者支持预编译语句，这样只能选择会话池模式。还有一些特例情况，某些业务场景只是单语句执行，那么语句池模式可能更适合。因此对比这三种模式，可以发现从对客户端操作的支持程度来讲，会话池支持度最高，其次是事务池，最后是语句池模式。但是从支持的连接数来讲，可能刚好是相反的顺序。

表 4 SQL特性对照表

上表为会话连接池和事务连接池的SQL特性对比情况，可以通过对比具体业务场景与SQL特性的符合度，来对连接池模式进行选型。

下面列举了一些示例场景：

• 有些只运行快速查询，因此在没有事务的情况下可以共享一个会话来处理上百个并发查询。
• 一些角色成员对于会话级并发是安全的，并且总是使用事务。因此，他们可以安全地共享数百个并发事务的多个会话。
• 有些角色过于复杂，无法与其他人共享会话。因此，您对它们使用会话池模式可以避免当所有“插槽”都已占用时连接错误。
• 不要使用它代替HAProxy或其他负载均衡器。尽管pgbouncer具有一些可配置的功能来解决负载均衡器要解决的问题，例如dns_max_ttl，并且可以为其设置DNS配置，但是大多数产品环境都使用HAProxy或其他用于HA的负载均衡器。这是因为HAProxy确实擅长以循环方式在服务器之间实现负载平衡，而不是pgbouncer。尽管pgbouncer对于postgres连接池更好，但最好使用一个小型守护程序来完美地执行一项任务，而不是使用较大的守护程序来完成两项任务，那样效果更糟。

在对于连接数的建议值来讲，上文也给出了一个大致的结果，就是一般情况下设置为CPU核数的3-4倍左右，当然这个不是绝对值，应该是在与业务场景类似的硬件环境中充分进行测试后，才能够得出具体的数值。

还有一点需要注意的是连接Pgbouncer的连接方式，网络连接和unix socket连接方式，较网络连接，unix socket方式可能更加节省网络通信的开销，因此如果pgbouncer和数据库在一台机器部署，可以优选该方式；如果处于不同服务器上，则选择网络连接。

作者简介

原文作者：王志斌，曾获得中国PostgreSQL数据库管理工程师（PGCE），是PostgreSQL官方认证讲师，盘古云课堂特邀金牌讲师。

本文仅代表作者个人观点，与官方无关。