Go 服务同时访问 Redis 与 PostgreSQL：连接池、超时和并发预算怎么拆

线上有个商品详情接口同时读取 Redis 和 PostgreSQL，大家踩得最多的坑就是上来就把两个组件的连接池都往大了调，短时间看QPS确实涨了，跑不了几分钟数据库就开始堵排队，Redis 侧也陆续冒出超时报错。更靠谱的思路是先把请求峰值并发、缓存命中率、数据库侧分配的可用连接数、单次请求的耗时预算这几个维度凑在一起对齐测算，再分别给两个客户端设置合理的上限。

Redis 连接池服务的是高频短请求，PostgreSQL 连接池服务的是有限的数据库并发；两者不能用同一个数。先按数据库承载能力定回源预算，再用缓存命中率倒推 Redis 与接口并发，最后用同一个 context 约束整条请求链。

先把一次请求拆成两条资源路径

假设商品详情接口的峰值并发是 240，正常缓存命中率约为 85%。命中 Redis 的请求只占用缓存连接；剩下约 15% 的请求会回源到 PostgreSQL。如果 PostgreSQL 集群给这个服务分配的安全活跃连接预算只有 36，那数据库连接池的上限肯定不能直接跟着 240 这个入口并发数走。

这里有两个很多人容易搞混的数字：接口同时能处理多少请求，和数据库同时允许执行多少条查询。前者是入口侧的请求压力，后者是下游数据库的实际承载容量。连接池越大不代表系统吞吐越高，一旦超过数据库能平稳消化的并发阈值，只会把排队逻辑从应用侧的连接池挪到数据库内部，反而拖慢整体响应。

可以先用一个保守模型估算数据库池：

回源并发 ≈ 接口峰值并发 × (1 - 缓存命中率)
数据库池上限 ≈ 回源并发 × 数据库查询占用比例 × 安全系数

按上面的数字，240 × 15% = 36 是回源请求的理论并发。如果接口还有额外的库存校验、偶发慢查询和批量刷新逻辑，数据库查询占用连接的比例可能接近满负载，实际池上限可以先设在 28～32，留出足够空间给管理查询、数据迁移和突发重试场景。

Redis 池和 PostgreSQL 池应该怎样分工

Redis 的请求链路通常短、响应快，天然适合承接接口的高并发入口流量；PostgreSQL 的连接资源要珍贵得多，应该把它当成受严格保护的回源通道。用 Go 生态里的常见客户端来配置的话，连接池参数完全可以分别体现这两个设计意图：

type PoolBudget struct {
    RedisMax int
    DBMax    int
}

var budget = PoolBudget{
    RedisMax: 128,
    DBMax:    32,
}

Redis 最大连接数不需要和服务跑的所有 goroutine 数量划等号，它只要能覆盖日常正常并发和少量突发流量就够；PostgreSQL 的最大连接数则要和数据库实例规格、读写副本配比、其他共享同库服务的连接额度放在一起综合计算。如果 PostgreSQL 前置用了 pgbouncer，应用侧的连接池上限还要服从 pgbouncer 的 server 端连接上限，不能把两个上限简单相加算总配额。

更关键的是取不到连接时的等待策略。Redis 拿不到连接时可以快速失败，直接走旧缓存或者返回兜底结果；数据库拿不到连接时，要让请求在接口总超时的约束下有序退出，不能在连接池里无限等待。不管是用 go-redis、pgxpool 还是标准库的 database/sql，都要把“等待池内可用连接”的耗时算进接口总耗时预算里。

用 context 把三层超时串起来

假设接口总耗时预算是 180 毫秒，分配给 Redis 查询的最多 35 毫秒，剩下的时间再全部分配给 PostgreSQL 查询。不要在下层函数内部单独新建一个比父请求生命周期更长的背景 context，不然用户侧已经放弃请求了，数据库侧的查询还会继续跑白白占用连接资源。

func loadProduct(parent context.Context, id string) (Product, error) {
    requestCtx, cancel := context.WithTimeout(parent, 180*time.Millisecond)
    defer cancel()

    cacheCtx, cancelCache := context.WithTimeout(requestCtx, 35*time.Millisecond)
    cached, cacheErr := redisClient.Get(cacheCtx, "product:"+id).Result()
    cancelCache()
    if cacheErr == nil {
        return decodeProduct(cached)
    }

    dbCtx, cancelDB := context.WithTimeout(requestCtx, 120*time.Millisecond)
    defer cancelDB()
    return queryProduct(dbCtx, id)
}

这段逻辑里没有把 Redis 的任意错误都直接判定成“缓存未命中”走回源。只有超时场景可以触发回源逻辑，像认证失败、协议错误或者 Redis 集群完全不可用这类问题要单独做指标统计，不然监控里只会显示一个模糊的 cache miss，排查问题的时候很容易误判是数据库性能掉底。

数据库查询超时后，先确认驱动已经收到取消信号，再观察连接池的等待耗时是不是逐步回落。只有请求本身已经很快返回，但池内连接长时间不归还的时候，才需要继续排查 rows 有没有正常关闭、事务有没有正确提交回滚、连接释放逻辑有没有漏写。

连接池耗尽时，如何判断是参数错还是下游慢

配置上线后不要只盯着接口平均耗时看。至少要落地四类核心指标统计：Redis 命中率、Redis 等待连接耗时、PostgreSQL 等待连接耗时、PostgreSQL 活跃连接数。再把这些指标按同一个时间窗口对齐对比，才能准确区分是“池配置太小不够用”还是“下游查询跑太慢拖垮整个链路”。

• PostgreSQL 活跃连接数接近设置的最大池上限，等待连接耗时持续上涨：优先排查慢查询和锁竞争，不要上来就直接调大连接池。
• 活跃连接数很低但等待连接耗时一直在涨：检查池配置是不是在所有实例上都生效了，或者有没有出现连接创建失败的异常。
• Redis 命中率突然下跌、数据库回源请求和等待耗时同时上涨：优先检查缓存键设计、过期策略和热点 key 淘汰逻辑。
• 请求已经超时但数据库活跃连接数迟迟不回落：检查查询取消逻辑、rows 资源关闭、事务回滚和驱动版本有没有已知问题。

一个很实用的压测顺序是先固定缓存命中率，再逐步拉高入口并发。比如先用 90% 命中率跑通基准性能，再模拟热点 key 集体失效的场景把命中率降到 60%。如果第二组测试里只是数据库活跃连接数翻倍，接口超时占比却大幅飙升，说明系统缺的是回源并发保护，不是一个更大的 Redis 连接池。

落地时保留一条明确的回退路径

配置正式上线前，给每个改动的参数提前定义好“出现什么现象就立刻回退”的触发条件。比如把 DBMax 从 24 调到 32 之后，如果 PostgreSQL 的锁等待占比、CPU 使用率或者 p95 耗时连续两个统计窗口都明显上涨，就先把配置恢复到 24，再慢慢优化 SQL 和事务逻辑，不要把回退和继续加大连接池混为一谈做连续操作。

缓存允许短暂返回旧值的场景，可以把降级逻辑写成显式的执行策略，不要在所有错误分支上直接静默吞掉异常：

if errors.Is(cacheErr, context.DeadlineExceeded) {
    metrics.CacheTimeout.Inc()
    return loadFromDatabase(requestCtx, id)
}
if isRedisUnavailable(cacheErr) {
    metrics.CacheUnavailable.Inc()
    return loadFromDatabase(requestCtx, id)
}

对价格、库存这类完全不能接受旧值的核心数据，宁可返回用户能识别的繁忙状态，也不能把“缓存超时后就直接回源”的逻辑无限放大。回源有自己的并发闸门做保护的时候，用户只会看到可控范围内的少量失败，数据库也不会被一次缓存故障直接打垮。

常见问题

Redis 连接池是不是越大越好？

不是。它会受到 Redis 单实例处理能力、网络带宽和客户端实际并发的多重限制。先观察连接等待耗时和命令执行耗时的变化，只有确认池内确实出现排队的时候才去调大上限。

PostgreSQL 池上限应该按 CPU 核数设置吗？

CPU 核数只能作为参考指标。还要综合考虑磁盘性能、锁竞争情况、查询复杂度、读写副本配比和同库其他服务占用的连接额度。应用侧的池上限必须小于这个服务被分配到的数据库连接总预算。

缓存超时后一定要回源数据库吗？

不一定。商品详情这类允许短暂返回旧值的场景可以直接走降级缓存；库存和支付状态这类核心数据要设置回源并发闸门，必要时直接返回可重试的繁忙状态。

如何确认 context 超时真的释放了数据库连接？

同时对照观察请求超时日志、数据库侧活动查询列表、连接池活跃连接数和等待连接耗时。压测流量停止之后，活跃连接数应该在很短时间内自然回落；如果没有回落，再去排查 rows 关闭、事务处理和驱动的查询取消逻辑有没有问题。

最后的配置检查

这类接口上线前，最有价值的不是抄来的一组万能参数，而是四个可以反复校验的核心数字：接口总耗时预算、缓存命中率、数据库池上限、回源闸门上限。它们分别对应最终用户的体验阈值、缓存层的实际效果、数据库的安全边界和故障场景下的止损底线。流量特征或者数据分布发生明显变化之后，重新跑一轮命中率下跌的模拟场景，再判断要不要调整现有配置。