Redis 客户端超时后连接还能复用吗：连接池回收、PING 与半开连接验收

线上看到 Redis 请求超时，最容易犯的错是立刻把连接池全部重建。对 go-redis 来说，业务命令超时、等待连接超时和连接本身不可用是三件事：先看错误发生在哪一层，再用一次带超时的 PING 验收，最后才决定是否让客户端退出回收。这样既不会把正常的慢请求误判成坏连接，也能把半开连接挡在后续流量之前。

一次请求超时不能直接证明连接坏了；只有在池等待、命令读写和独立 PING 都指向不可用时，才应该回收客户端并重新建立连接池。

先把三种超时分开看

在 go-redis v9 中，PoolTimeout 控制的是“所有连接都忙时，调用方最多等多久”。如果日志里出现 redis: connection pool timeout，优先检查的是并发占用、慢命令和池容量，而不是马上执行重连。另一类是命令的读写超时，例如 Redis 已经收到请求，但客户端没有在 ReadTimeout 内拿到响应；这时连接是否可复用，需要再做一次健康检查。

下面这组参数只用于复现边界，数值不是通用推荐值。关键是让日志同时记录 PoolSize、PoolTimeout 和每次 PING 的耗时：

rdb := redis.NewClient(&redis.Options{
    Addr:        "127.0.0.1:6379",
    PoolSize:    8,
    PoolTimeout: 200 * time.Millisecond,
    ReadTimeout: 500 * time.Millisecond,
    WriteTimeout: 500 * time.Millisecond,
})

图里的分支对应的是排查顺序：先辨认池等待，再辨认命令读写，最后让 Ping 给出可复核的健康结果。不要把“请求慢”直接画成“连接已坏”。

命令超时后，先用 PING 验收连接路径

业务请求返回超时后，单独创建一个短生命周期的检查上下文。这里的 Ping 只回答当前客户端到 Redis 的往返是否还能完成，不能证明刚才那条业务命令已经执行或回滚；业务层是否重试，要根据命令幂等性另行决定。

func checkRedis(ctx context.Context, rdb *redis.Client) error {
    checkCtx, cancel := context.WithTimeout(ctx, 300*time.Millisecond)
    defer cancel()

    pong, err := rdb.Ping(checkCtx).Result()
    if err != nil {
        return fmt.Errorf("redis ping failed: %w", err)
    }
    if pong != "PONG" {
        return fmt.Errorf("unexpected redis ping reply: %q", pong)
    }
    return nil
}

验收时把三条信息放在同一条日志里：原命令错误、Ping 结果、当前池等待指标。若原命令超时但 PING 正常，先查慢命令或 Redis 负载；若 PING 也超时，才进入连接回收路径。

什么时候应该回收 Client，而不是继续借连接

如果 PING 连续失败，或者错误已经明确指向底层连接不可用，当前客户端继续借连接只会把问题扩散到更多请求。回收动作要集中在一个拥有客户端生命周期的组件中，调用 Client.Close 后再由上层构造新的客户端；不要在每个请求处理函数里随手 new 一个连接池。

func closeRedis(rdb *redis.Client) error {
    if err := rdb.Close(); err != nil {
        return fmt.Errorf("close redis client: %w", err)
    }
    return nil
}

这里有一个实际边界：只有一次业务命令超时、随后 PING 成功时，不建议立即 Close。相反，连续健康检查失败、连接被底层读写错误标记为不可用，或者应用正在执行明确的故障切换时，回收才是有依据的动作。

用一轮小压测确认池等待是不是根因

把并发请求数从 4、8、16 逐级提高，每组只观察三项：业务命令耗时、PoolTimeout 次数、PING 失败次数。若并发从 8 提到 16 后池等待明显增加，而 PING 始终成功，问题更像池容量或慢命令占用；若两者同时恶化，再检查网络、Redis 事件循环和客户端读写超时。

常见问题

PoolTimeout 是 Redis 服务端满了吗？

不一定。它首先表示客户端连接池没有在限定时间内提供连接，常见原因是并发太高、命令太慢或池容量偏小。服务端拒绝连接应查看另一组连接错误和 Redis 服务端日志。

PING 成功能证明刚才的 SET 一定成功吗？

不能。PING 只证明检查时的客户端到 Redis 路径可通，不能替代业务命令的结果确认。写命令是否重试，仍要看命令幂等性和业务确认方式。

为什么不为每个请求单独创建 Redis 客户端？

这样会反复创建连接池，放大连接数和握手开销，也让回收责任变得模糊。通常应让一个进程或服务组件持有长期客户端，在生命周期结束时统一调用 Client.Close。

把复查结果留在日志里

一次合格的复查至少包含：原始错误类型、PoolTimeout 是否出现、PING 是否返回 PONG、是否调用了 Client.Close，以及对应的并发和时间窗口。记录齐后，下一次告警才能判断是容量问题、慢命令问题，还是连接路径真的失效。