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官方认证讲师，盘古云课堂特邀金牌讲师。

本文仅表明做者我的观点，与官方无关。