错误码怎么读
对象存储的错误响应是一份结构化文档，里面既有简短的错误码也有请求标识。区分「请求本身有问题」与「服务端让你慢一点」是排障的第一分岔：前者重试多少次都不会成功，后者只要退避得当就能恢复。相反，把限流当成程序缺陷去改代码，或把参数错误当成偶发故障去疯狂重试，都会把问题放大。
基本信息
| 响应形式 | HTTP 状态码 + 结构化错误文档 |
|---|---|
| 关键字段 | 错误码、错误信息、请求标识、主机标识 |
| 客户端错误 | 鉴权失败、对象不存在、参数非法等，重试无效 |
| 服务端错误 | 限流与临时不可用，应按退避策略重试 |
典型场景与处理
- 请求速率过高：服务端明确要求降速，必须退避并加抖动
- 前缀热点：同一前缀的请求过于集中，需要打散写入分布
- 鉴权失败：签名或权限问题，重试无意义，要核对密钥与策略
- 对象不存在：注意版本化场景下可能是删除标记造成
- 请求超时：先判断客户端超时设置与业务实际耗时是否匹配
重试策略要点
重试策略要点
# 只对可恢复错误重试：限流与临时不可用
# 指数退避：每次失败后等待时间翻倍，并加入随机抖动
# 上限保护：设定最大重试次数与最长等待，避免线程长期占用
# 幂等前提：写入同名对象可重试；分片上传需按上传标识恢复
# 全局限速：并发过高时应主动降速，而不是把重试当并发补偿
# 记录请求标识：便于与服务端记录对齐，判断是限流还是真实故障常见错误对照
| 类别 | 典型含义 | 处理方向 |
|---|---|---|
| 限流类 | 请求速率超过服务端可承受范围 | 退避重试并降低并发，必要时打散前缀 |
| 鉴权类 | 签名不匹配或权限不足 | 修正密钥、签名范围与策略授权 |
| 不存在类 | 键名写错或已被删除 | 核对键名编码与版本状态 |
| 临时不可用类 | 服务端短暂异常 | 适度重试并观察是否成规模发生 |
| 参数类 | 请求格式或取值不合法 | 按接口文档修正请求，不要重试 |
工程实践建议
- 重试策略在客户端库与业务代码里统一，避免多层各自重试造成叠加放大
- 把限流指标纳入监控并设置告警，限流长期发生说明容量或设计需要调整
- 批量任务要有节流阀，按服务端反馈动态调整速率
- 对不可恢复错误快速失败并记录，避免无效重试掩盖真实问题
- 保留请求标识，跨客户端与服务端排查时这是最有效的关联线索
限流是保护机制而非故障：它通常意味着当前请求模式超出了服务端的分区处理能力，单纯换账号或换端点并不能解决。
重试必须有上限与退避，无上限的紧密重试会在高负载时形成重试风暴，把可自愈的限流放大成全站不可用。