一、把总延迟拆成可测量的阶段
总延迟 =
业务事件到入队时间
+ 内部队列等待
+ API请求耗时
+ 平台处理和路由时间
+ 运营商传输时间
+ 用户设备接收时间如果只记录“点击发送”和“用户反馈收到”的时间，就无法判断延迟发生在哪里。建议为业务创建、入队、API提交、平台接收、发送和送达分别记录时间戳。
API耗时请求到平台响应
队列等待创建到真正提交
平台耗时接收到交给运营商
端到端耗时业务触发到最终送达
二、不要只看平均值
平均延迟可能掩盖少量非常慢的消息。OTP业务应至少观察p50、p95和p99：p50反映普通用户体验，p95和p99反映高延迟用户比例。
| 指标 | 含义 | 用途 |
|---|---|---|
| p50 | 一半短信在该时间内送达 | 观察典型体验 |
| p95 | 95%短信在该时间内送达 | 发现尾部延迟 |
| p99 | 99%短信在该时间内送达 | 监控极端异常 |
| 超时比例 | 超过业务有效期的消息比例 | 评估OTP和提醒是否失效 |
指标还应按国家、运营商、Sender ID、模板和短信类型拆分，避免某个高流量市场掩盖其他市场异常。
三、内部队列和流量优先级
大型营销活动可能瞬间产生大量请求，如果验证码和营销短信共用同一队列，OTP会被低优先级任务阻塞。建议分别建立高优先级验证码队列、事务通知队列和批量营销队列。
- 为OTP保留独立并发和吞吐量。
- 设置队列最大等待时间和积压告警。
- 批量活动使用平滑发送，不瞬间提交全部号码。
- 对同一用户和号码设置频率控制。
- 在流量激增时优先保障高价值事务消息。
四、API和连接层优化
应用应复用HTTP连接，设置合理连接和读取超时，并避免在每次发送前执行不必要的同步数据库或第三方请求。批量接口适合非实时任务，验证码则通常更适合单条或小批次快速提交。
发生超时时不能直接认为请求失败。应使用幂等键或业务流水号查询原请求状态，防止重复发送。客户端重试需要指数退避、最大次数和随机抖动。
五、平台路由和运营商延迟
延迟集中在特定国家或运营商时，需要检查路由质量、Sender ID、当地过滤和高峰时间。部分通道价格较低但路径更长，不适合对时效要求高的OTP。
测试应使用真实设备和多个运营商。若平台提供路由或运营商维度报告，应比较各路线的送达率和延迟，而不是只看总体表现。切换路由后要进行小流量验证，避免新的失败风险。
建议：OTP、账户安全和关键告警应优先选择稳定低延迟路由；营销短信更关注合规、成本和吞吐量，不能完全共用同一策略。
六、设备、漫游和用户行为
用户设备关机、无信号、漫游、双卡设置或网络切换会增加接收时间。此类延迟不一定能通过平台优化完全消除，因此前端体验也很重要。
验证码页面应显示合理倒计时，不要过早开放重复发送；再次发送时应明确旧验证码是否失效。可以提供备用验证方式，但要避免多个渠道同时发送造成混乱。
七、超时与重试策略
| 场景 | 建议 |
|---|---|
| API连接失败 | 短暂退避后重试，使用幂等键 |
| API超时但状态未知 | 先查询原请求，避免重复提交 |
| 平台限流 | 降低并发并按Retry-After或退避规则重试 |
| 设备暂不可达 | 根据业务有效期有限重试 |
| 验证码已过期 | 停止旧消息重试，生成新验证流程 |
八、持续优化检查清单
- 记录每个阶段的时间戳并计算p50、p95和p99。
- 按国家、运营商、模板和路由拆分延迟。
- 为OTP、通知和营销流量建立独立队列。
- 监控API耗时、队列积压、回调延迟和超时比例。
- 定期使用真实设备进行多运营商测试。
- 结合用户验证成功率，而不是只看送达状态。
- 对延迟突然上升设置自动告警和降级策略。