IOSOR 知识库

A TPS 限制与队列机制 — 绝不静默丢弃

了解 IOSOR 如何通过对 SMS 流量进行排队而非静默丢弃来处理吞吐量限制，从而确保准确的 DLR 跟踪和 Webhook 更新。

A TPS 限制与队列机制 — 绝不静默丢弃。

理解 TPS 限制与队列机制

在发送大容量的 OTP(一次性密码)和 SMS 营销活动时，达到每秒交易量(TPS)限制是不可避免的。在一个专业的白标 CPaaS 环境中，超出此限制绝不应该导致消息的静默丢失。相反，IOSOR 实施了严格的队列机制。当您的出站速率超过分配的 TPS 时，消息将被放入基于内存的缓冲区中。这确保了每个 E.164 目的地都按顺序进行处理，而不会丢失任何有效载荷数据。通过这种缓冲，您的系统可以平稳地度过流量高峰，而无需在客户端进行复杂的重试逻辑。

为什么静默丢弃正在破坏您的送达率指标

静默丢弃是指 API 接受了消息载荷，但在没有生成状态报告(DLR)的情况下将其丢弃。这会严重破坏您的应用程序逻辑，因为您的系统会错误地认为消息仍在传输中。在 IOSOR 中，流量超限会触发明确的队列状态。如果队列深度超过了安全阈值，API 将返回速率限制状态或将该项置于待处理状态。您将始终收到 Webhook 更新或即时的 API 错误，而绝不会陷入信息黑洞。这使您能够对最终用户保持完全的透明度，并维护高标准的交付质量。

账本预扣与即时(JIT)号码分配

为了保持绝对的财务准确性，IOSOR 采用了预付费账本系统。当消息进入队列时，系统会在您的余额上进行临时的预付费扣留。如果您正在配置新号码，我们的即时(JIT)系统只有在路由处于活动状态时才会分配 E.164 资源并收取每月循环费用(MRC)。这可以有效防止余额泄漏。我们强制执行最低 USD 20 的预付费门槛以保持您的账户处于活动状态。当您的月度消费接近 USD 1,000/month 时，我们将启动软性评估，以优化您的自定义 TPS 限制并提供更具竞争力的费率。

针对队列中和受限流量的 Webhook 状态

每一个消息状态的变化都会通过 Webhook 进行广播。当消息受到流量限制时，其状态会转变为 'queued'(已排队)而不是 'failed'(失败)。一旦 TPS 容量允许，消息就会被发送，状态随之转变为 'sent'(已发送)，并在收到运营商 DLR 后最终变为 'delivered'(已送达)。如果用户回复了 STOP，系统会立即停止向该目的地发送后续的排队项，并返回 'skipped'(已跳过)状态，以防止违反合规性要求。这种细粒度的状态跟踪使您的运营团队能够实时掌握每一条消息的去向。

从 IOSOR 开始

在大规模发送流量前，请前往 IOSOR 控制台检查每秒事务数（TPS）限制与队列深度阈值。配置您的 Webhook 接收器以捕获明确的"已排队"状态转换，从而确保应用程序能够正确识别受到流控的请求。请核实您的后端能够识别排队消息的账本预留状态，而不会将限速分发误判为缺失的投递报告（DLR）。

IOSOR 要点

在 IOSOR 中超出 TPS 上限绝不会导致未跟踪的静默丢弃或未经确认的消息丢失。该平台强制执行显式的停止并排队工作流，使您的有效负载保持完整，应用临时余额冻结，并广播"已排队"状态，直到吞吐量容量恢复。

请监控 Webhook 状态事件，以跟踪消息从排队无缝转换为已发送和已交付。当有效负载量超过分配的吞吐量上限时，切勿建立超时假设或将限速误认为是流量丢失。

这篇指南有帮助吗？