数据库接入文档的核心任务之一，是让应用在连接池与读写分离的配合下，既保持低延迟，又具备高可用。很多团队在接入时，要么只配置了连接池而忽略读写分离，要么在读写分离后遭遇数据不一致。本文以三个典型场景串联配置步骤，帮助你判断何时需要连接池、如何设计读写分离，以及怎样避开常见陷阱。
场景一：连接数打满，应用响应变慢
当你的应用实例增多，或单个实例的并发请求上升，数据库连接数往往最先成为瓶颈。每个新连接都要经历 TCP 握手、认证、内存分配等过程，频繁创建和销毁连接会显著增加延迟和数据库负载。此时，连接池是标准解法：复用一组已建立的连接，按需分配，用后归还。
以 PostgreSQL 为例，官方文档强调连接是重量级资源，每个连接都会消耗内存和 CPU 资源。配置连接池时，你需要关注几个参数：最小连接数、最大连接数、空闲超时和获取连接超时。最小连接数保证低峰期也有可用连接；最大连接数防止应用无限制占用数据库资源；空闲超时回收长期不用的连接；获取连接超时则避免应用无限等待。
一个典型配置步骤如下：
- 评估应用并发峰值，估算所需连接数。通常，每个应用实例的连接数可设置为 (CPU 核心数 × 2) 加上少量缓冲。
- 在应用层选择连接池实现，如 HikariCP（Java）、pgbouncer（PostgreSQL 专用）或 Redis 的客户端连接池。
- 设置最大连接数，并确保数据库侧的最大连接数（如 PostgreSQL 的 max_connections）大于所有应用实例的连接池总和，否则数据库会拒绝新连接。
- 配置空闲超时，例如 300 秒，避免空闲连接占用资源。
- 设置获取连接超时，例如 5000 毫秒，超时后抛出异常，避免应用线程堆积。
失败条件很常见：如果连接池最大连接数设置过大，数据库可能因资源耗尽而崩溃；如果过小，则请求会排队等待。AWS 可靠性指南建议，在设计连接池时，要考虑数据库的承受能力，并预留缓冲以应对突发流量。另外，连接池的监控必不可少，至少需要关注活跃连接数、空闲连接数和等待获取连接的线程数。
场景二：读多写少，主库压力大
大多数业务是读多写少，比如内容网站、电商商品展示。若所有读请求都打到主库，主库的 CPU 和 IO 会很快成为瓶颈。读写分离将读流量分散到只读副本，主库专注于写操作，从而提升整体吞吐量。但引入读写分离后，必须处理数据延迟带来的不一致问题。
以 PostgreSQL 为例，你可以通过流复制创建只读副本。应用层需要区分读操作和写操作：写操作（INSERT、UPDATE、DELETE）必须路由到主库；读操作（SELECT）可以路由到只读副本。实现方式有两种：在应用代码中显式指定数据源，或使用中间件（如 ProxySQL、Pgpool-II）自动路由。
配置步骤通常如下：
- 创建只读副本，确保主库和副本的 schema 一致。
- 配置复制延迟监控，确保副本数据足够新。
- 在应用层或中间件层配置读写分离规则。例如，根据 SQL 类型（SELECT 走副本，其他走主库）或根据事务边界（事务内的读必须走主库）。
- 为只读副本设置独立的连接池，避免与主库争抢连接。
- 对于需要强一致性的读操作（如用户余额查询），强制路由到主库。
常见误区是忽略复制延迟。PostgreSQL 流复制默认是异步的，副本可能落后主库数秒甚至更久。如果业务允许最终一致性，可以接受；否则需要同步复制或使用版本号机制。AWS 可靠性指南也指出，在分布式系统中，数据复制延迟是影响可用性的关键因素，你需要明确业务对一致性的要求。
另外，读写分离后，主库和副本的连接池配置可能不同。副本通常需要更多的读连接，而主库需要保留足够的写连接。如果副本故障，应用应能自动降级到主库，避免读请求失败。
场景三：缓存与数据库混合，如何保持一致性
很多系统使用 Redis 作为缓存，以减轻数据库压力。但缓存与数据库的数据一致性是经典难题。常见策略是 Cache-Aside：先读缓存，未命中则读数据库并回填缓存；写操作则先更新数据库，再删除缓存或更新缓存。
Redis 官方文档提供了多种缓存模式，其中 Cache-Aside 是最常用的。接入时，你需要考虑缓存失效策略和缓存穿透、击穿、雪崩等问题。连接池在缓存层同样重要，Redis 客户端通常内置连接池，你需要合理设置最大连接数和超时时间，避免缓存成为新的瓶颈。
一个典型配置流程：
- 选择合适的 Redis 客户端，启用连接池，设置最大连接数（如 50）和空闲超时（如 300 秒）。
- 设计缓存 key 和过期时间，避免热点 key 同时过期。
- 实现 Cache-Aside 逻辑：读请求先查缓存，未命中查数据库并回填；写请求更新数据库后，删除对应缓存。
- 监控缓存命中率、连接池使用率和 Redis 内存，及时调整容量。
常见误区包括：更新数据库后直接更新缓存而不是删除，这可能导致并发下数据不一致；或者缓存过期时间设置过长，导致数据长期陈旧。Redis 官方文档建议根据业务需求设置合理的 TTL，并使用随机过期时间避免雪崩。
此外，连接池与读写分离并非孤立，它们需要协同工作。例如，当只读副本延迟较高时，你可以临时将读流量切回主库，或通过缓存缓解。AWS 可靠性指南强调，设计需要考虑到组件的故障模式，并准备降级策略。
连接池与读写分离的常见误区
误区一：连接池越大越好。实际上，连接池过大会增加数据库上下文切换开销，甚至导致数据库崩溃。最佳实践是设置一个合理的上限，并通过监控调整。
误区二：读写分离后所有读都走副本。事务内的读操作必须走主库，否则可能读到未提交的数据。另外，对于强一致性的读，也要走主库。
误区三：忽略连接池泄漏。如果应用代码没有正确归还连接，连接池会被耗尽。务必使用 try-with-resources 或类似机制确保连接释放。
误区四：缓存一致性只靠删除。在并发场景下，删除缓存也可能导致缓存击穿。可以使用双删策略或延迟双删，但更可靠的是使用版本号或消息队列。
总结与行动清单
数据库接入文档的核心在于，根据业务场景选择合适的连接池配置和读写分离策略。你需要持续监控数据库和缓存的指标，如连接数、延迟、复制延迟、缓存命中率，并根据数据调整配置。AWS 可靠性指南建议，定期进行故障演练，验证连接池和读写分离在故障时的表现。
最后，务必阅读官方文档：PostgreSQL 文档提供详细的连接和复制配置，Redis 文档提供缓存模式最佳实践，AWS 可靠性指南提供架构级指导。这些资源能帮助你避免常见的坑。
参考资料
延伸阅读