超时要分层设置
超时按层拆分才合理：连接超时最短，用于在建立链路阶段快速失败；读超时按业务可接受的最慢响应留余量，通常参考 p99 再加一点；总超时封顶整次调用，防止各阶段各等一遍把时间耗光。设置过短会误杀正常的慢查询并触发重试放大，设置过长则资源被慢请求长期占住，故障时整体不可用。
基本信息
| 连接超时 | 最短，通常几百毫秒，追求快速失败 |
|---|---|
| 读写超时 | 参考 p99 加余量，避免误杀正常请求 |
| 总超时 | 不超过业务可接受上限，作为最终封顶 |
| 重试策略 | 与超时配套，限制次数并加退避 |
| 取值依据 | 来自自测的延迟分布，容量或链路变化后复评 |
典型使用场景
- 接口设计：给每个下游依赖单独定超时，避免一个慢依赖拖垮整条链路
- 重试治理：区分可重试与不可重试错误，防止重试风暴
- 降级配合：超时后走降级分支返回兜底数据
- 容量变化：扩容或跨区部署后重新核对超时是否仍然合适
- 告警定阈：把超时率作为核心指标，而不是只盯平均延迟
先量再定
先量再定
# 客户端超时示意（参数名以所用库文档为准）
# connect_timeout=200ms, read_timeout=500ms, total_timeout=1000ms
redis-cli --latency-history -i 15 # 看往返延迟的波动区间
redis-cli SLOWLOG GET 20 # 取慢命令样本，看最慢能到多少
redis-cli INFO commandstats | grep usec_per_call # 按命令看平均耗时
redis-cli INFO latencystats # 若已开启，看命令延迟分位分层设置建议
| 层级 | 设置思路 | 偏离的后果 |
|---|---|---|
| 连接超时 | 几百毫秒内快速失败 | 过短会把链路抖动判成不可用 |
| 读超时 | p99 之上加余量 | 过短误杀正常慢查询，过长长期占资源 |
| 总超时 | 业务可接受上限 | 过长让慢请求拖住线程池 |
| 重试次数 | 少量次数加退避 | 过多形成重试风暴放大故障 |
超时数字要来自自测数据而不是拍脑袋：先量出接口延迟分布与命令耗时分布，再按业务容忍度选值，并在容量与链路变化后复评一次。
超时若不分类，业务侧只能看到「失败」，无法区分瞬时抖动与真实故障。把连接失败、读超时、服务端错误分别计数，后续决策才有依据。