高并发应用程序的数据库连接池指南
高并发应用程序可能同时建立大量数据库连接，超出数据库可以稳定处理的范围。如果每个请求都重新建立连接，认证、TLS 协商、会话设置及关闭连接都会增加延迟，数据库也要耗用资源来管理大量短暂会话。数据库连接池会保留一组受控的现有连接供重用，让请求借用连接、完成工作后归还，而不用每次重复完整的建立流程。
连接池不能取代查询优化或容量规划，而是把应用程序的并发量与数据库容量分隔开来。在独立服务器上，团队可以按 CPU、内存、存储、网络及数据库设置调整连接池上限，再通过监测确认它是否改善响应时间，而不是把排队问题转移到其他层。
数据库连接池如何运作
连接池会按设置建立连接，并保留空闲连接待重用。当应用程序需要数据库时，会等待可用连接，借用它完成事务或会话，再于工作完成后归还。对于过时、损坏或使用时间过长的连接，连接池会进行验证或将其淘汰。
数据库连接池只是整体应用程序设计的一环。Dataplugs 的实时协作平台托管基础设施文章说明，互动式工作负载需要一并规划低延迟、共享状态、连接管理及数据库容量。
- 应用程序借用空闲连接，而不是每个请求都重新建立连接
- 每个应用程序实例的连接池上限，会限制同时进行的数据库工作量
- 空闲、存活时间及验证规则可移除过时或不健康的连接
- 获取连接超时可揭示压力，避免请求无限期等待
- 事务池化与会话池化会保留不同程度的数据库状态
为什么高并发会造成连接压力
并发量不等于数据库容量。网页层可以接收数以千计的请求，但数据库在同一时间能够有效执行的查询可能少得多。没有连接池时，流量突增可能造成连接风暴：CPU 和内存被连接管理消耗，会话之间频繁切换，锁定时间延长，数据库更可能在有效工作完成前拒绝新连接。
连接池不能让无限并发变得安全。它会在应用程序内为超出上限的请求排队，并为数据库设定较可预测的连接预算。Dataplugs 的独立托管备份及灾难恢复贴士也指出，与其依赖单一控制，不如同时订立恢复目标、监测基础设施及测试故障流程。
- 设置数据库实际能够支持的每个实例连接池上限
- 使用获取连接超时，连接池耗尽时返回清晰的过载响应
- 为管理、监测及恢复预留连接或容量
- 把网页池以外的后台工作、迁移及维护任务一并计算
- 除了数据库查询时间，也要监测排队时间
如何规划连接池容量
连接池容量应先以数据库能够有效处理的并发量为起点，再用实际数据验证。当数据库仍有空闲 CPU 且存储速度足够时，增加连接池可能提升吞吐量；但当查询互相争用 CPU、锁或 I/O，过大的连接池反而会降低吞吐量。在多实例应用程序中，总连接数上限是每个实例连接池大小乘以实例、工作程序或进程数量。
容量规划应按实际请求量、查询时间、事务时间、数据库连接上限及故障切换需要进行。Dataplugs 的季节性网站流量高峰资源分配文章介绍如何以实测 CPU、内存、存储及带宽需求规划独立基础设施，而不是只按照平均值估算。
- 计算所有应用程序实例的总连接池容量
- 让总数低于 max_connections，并为管理员预留空间
- 量度活跃连接、空闲连接、等待者及获取连接延迟
- 测试正常流量、突发流量、慢查询及部分数据库故障
- 只有在数据库有能力使用时才增加连接池
提示：过大的连接池往往会掩盖真正的瓶颈。调整上限前，应比较连接池等待时间、查询延迟、CPU 饱和度、锁等待及存储延迟。
连接存活时间、空闲超时及事务边界
连接池中的连接会保留会话状态，除非连接池或应用程序主动重置。残留的 search_path、角色、隔离级别、临时表、预备语句或未完成事务，可能把行为带到下一个请求。应在借用及归还流程中重置应用程序可以修改的状态，而每个事务都必须在释放连接前提交或回滚。
- 连接存活时间同样重要。数据库故障切换、防火墙空闲超时、网络变更及服务器重启，都可能令连接池中的套接字看似可用，实际上已经无法使用。应使用健康检查、最长存活时间、空闲清除及会丢弃损坏连接的重试规则。对于结果不确定的网络故障，不要盲目重试非幂等写入。
- 每次提交或回滚后都要归还连接
- 让下一个请求使用连接前先重置会话状态
- 使用最长存活时间及空闲清除，避免连接变得过时
- 长时间空闲后或进行重要工作前验证连接
- 按操作及事务设计，确保重试行为安全
会话池化与事务池化
会话池化会让一个客户端在整个会话内使用同一个数据库连接，适合依赖会话变量、临时表或预备语句的应用程序，但当很多客户端空闲时会使用较多连接。事务池化则会在每次事务后归还连接，让更多客户端共享较小的数据库连接预算，但不能假设会话专属功能会持续存在。
应按应用程序框架及数据库功能选择模式。连接代理可以改善重用率，但也会增加另一个故障范围及一组需要监测的指标。应记录池化发生在哪一层、哪一层负责 TLS、凭证如何轮换，以及故障切换时客户端和代理如何丢弃旧连接。
- 当应用程序依赖会话状态时使用会话池化
- 当短事务需要高重用率时使用事务池化
- 不要在等待外部 API 或用户输入时长时间保持事务开启
- 检查 ORM、预备语句及 advisory lock 的兼容性
- 在部署、故障切换及滚动重启期间测试连接池
故障切换及维护期间的连接池行为
数据库节点提升为主节点后，连往旧主节点的现有连接可能仍保持连接，但已经无法进行写入。应用程序和连接池需要清晰的端点策略、健康检查，以及排空或丢弃连接的方法。稳定的代理或服务端点可以简化路由，但仍需协调提升、隔离旧节点及应用程序重试。
在独立服务器上，应测试完整流程：检测故障、停止向旧节点派送新工作、更新写入端点、清除过时连接、以退避方式重连，以及验证数据一致性。通过有上限的重试、抖动及受控的恢复并发量，避免连接池在恢复期间造成重连风暴。
- 定义读取端点和写入端点的使用方式
- 提升主节点或出现网络分区后，标记旧连接为不可用
- 使用指数退避及抖动重新连接
- 限制同时进行的恢复及迁移工作
- 记录连接池错误、故障切换时间及首次成功写入
总结
数据库连接池让高并发应用程序可以受控地重用连接、保护数据库容量并减少建立连接的延迟。最稳健的设计会把经量度的池化容量，与事务清理、生命周期规则、可观测性、安全的故障切换行为，以及足够的独立 CPU、内存、存储和网络余量结合。
如要为应用程序服务器、数据库系统及连接代理配置可预测的单租户容量，Dataplugs 提供具备可配置 CPU、内存、存储和网络选项的独立服务器方案。
如需了解更多，请访问 Dataplugs 或联系 sales@dataplugs.com。