第二条短信通道：DLR 移交操作手册

第二条短信通道：DLR 移交操作手册。

双通道 DLR 冲突模式

为大批量 OTP 流量添加第二条路由会产生状态同步风险。当主通道停滞时，传入的交付回执（DLR）会与次要分发定时器发生冲突。如果没有确定性的状态映射，平台会触发重复重试，燃烧预付费钱包中的资金，并可能在理解接近软审查阈值之前推高上游费用。

交付回执同步机制

每个终端状态更新都必须带有严格的序列标签。在桥接两个网络合作伙伴时，系统将特定于供应商的状态代码规范化为统一的平台事件。这种同步可防止触发不必要回退尝试的误报超时。通过 webhook 接收 DLR，并立即与内部消息队列中的原始请求进行匹配，确保 DLR 的准确性。

避免双重重试计费陷阱

当主运营商处理延迟的 DLR 时，通过辅助路径重试未确认的有效负载会导致双重终止。为防止这种情况，请对消息 UUID 实现原子锁。一旦分发了出站有效负载，辅助队列就会在释放之前检查分布式状态。在控制台监控 DLR 状态，确保同一消息的 DLR 不会跨越两条通道重复触发计费。

与核心路由操作集成

管理多路径效率需要持续监督网络性能指标。运营商应将流量分布与 规模化短信路由与运营 指南结合起来审查，以在无需人工干预的情况下维持基准交付率。特别关注 DLR 的时延（latency）和成功率，这直接影响到用户体验和成本控制。

安全处理故障转移差异

当主阈值突破可接受限制时，必须在不丢失挂起状态上下文的情况下发生自动迁移。参考 实时流量下的故障转移操作手册 在重流量负载下执行干净的通道切换。在切换过程中，确保 DLR 的有序性，避免因通道切换而产生混乱的 DLR 状态。研究 回执、时延与故障转移 以保护利润率。

从 IOSOR 开始

选一条已备好第二条路由的 OTP 走廊。发一条消息，中途切路径，把两次 DLR 到达导出到同一 correlation ID。标明哪张回执是旧 hop、哪张是新 hop。两张绿灯回执不是两次送达。下一批发出前，把这份导出交给路由负责人。在控制台查看消息的完整生命周期，包括发送、DLR 接收和通道状态变化。

IOSOR 要点

第二条路由交接是 DLR 身份转移，不是新战役。在执行此操作时，务必考虑“静默期”或“静默小时”的设置，以避免在流量高峰期进行不必要的通道切换，从而影响 DLR 的准确性。确保预付费钱包有足够余额以应对潜在的 DLR 延迟或错误处理。

要做：切换全程只用一个 correlation ID；在 ledger 上标旧 hop 对新 hop。确保 DLR 的 webhook 配置正确，能够及时接收并处理来自不同通道的回执。

不要：把两张回执当成两次发送，或在从未接管该消息的路径上显示 Delivered。避免在 DLR 处理过程中出现“静默小时”的误判，导致 DLR 被错误地归类或丢弃。