---
title: "每天发送数百万条短信：高并发短信发送指南"
description: "每天发送数百万条短信：TPS 规划算法、SMPP 绑定与窗口、队列与限速、送达回执处理、发送方 ID、静默时段和监控指标，适合国际短信群发团队。"
canonical: "https://omnichannels.ai/zh/blog/high-volume-sms-sending-guide/"
language: "zh"
updated: "2026-11-02"
publisher: "BroadNet Technologies"
brand: "OmniChannels.ai"
category: "sms"
primaryQuery: "send millions of sms per day"
keywords: ["短信群发 高并发", "短信 TPS 吞吐量", "SMPP 窗口大小", "大批量国际短信", "SMPP 绑定", "短信队列限速", "送达回执处理"]
published: "2026-11-02"
author: "OmniChannels.ai Editorial Team"
reviewer: "BroadNet Messaging Solutions Team"
readingMinutes: 11
answer: "要每天发送数百万条短信，应按峰值而不是日均值规划吞吐量：用必须发送的短信分段数除以发送窗口的秒数，为验证码流量预留余量，并把 SMPP 窗口设为至少 TPS 乘以往返时间。使用多个绑定、按运营商划分的队列，以及遇到限流错误会退避的限速器，单独处理送达回执，并把验证码和促销流量分开。"
takeaways: ["每天一千万条消息，平均每秒只有约 116 条，但把一次促销挤进四小时窗口则需要每秒约 694 条，而每多一个分段，这个数字就要成倍增加。", "SMPP 规范允许发送方在不等待响应的情况下连续发出多个请求；未完成请求的数量由实现自行决定，因此窗口需要协商和调优。一个好的起点是：窗口至少为 TPS 乘以以秒计的往返时间。", "限流（ESME_RTHROTTLED，0x58）和队列已满（ESME_RMSGQFUL，0x14）是让您放慢速度并退避重试的信号，而不是立即重发。", "送达回执是第二条高流量数据流：规划回执的消费者、存储和对账时，要像规划提交那样仔细。", "容量是与服务商按账户和线路约定的；请以书面形式索取您的峰值数据，并在上线前测试。"]
faq: 
  - q: "发送一百万条消息，每秒需要发多少条短信？"
    a: "用分段数除以发送窗口的秒数。一小时内发送一百万条单段短信，每秒约需 278 条；四小时内约需 69 条；分散在一整天则约需 12 条。多数平台按每个分段计一次，所以两段的短信会让所需速率翻倍。"
  - q: "SMPP 窗口大小是什么？如何设置？"
    a: "窗口是您可以同时处于未完成状态的 submit_sm 请求数量，即已发送但尚未得到应答的请求。SMPP 规范允许异步请求，但把上限留给实现自行决定。一个实用的规则是：窗口至少为目标 TPS 乘以以秒计的往返时间，然后只在服务商同意的上限内提高，因为超出会导致限流。"
  - q: "高并发需要多少个 SMPP 绑定？"
    a: "取决于您的峰值速率、服务商约定的每个绑定的限速，以及您的冗余需求。用峰值 TPS 除以约定的每绑定速率，向上取整，再至少增加一个备用，这样断线不会使发送中断。把验证码流量放在独立的绑定或账户上。绑定按账户开通。"
  - q: "收到 ESME_RTHROTTLED 该怎么办？"
    a: "放慢速度。规范将 ESME_RTHROTTLED（0x58）定义为发送方超出了允许的消息限制。请暂停或减少提交，对被拒绝的消息使用带抖动的指数退避重试，绝不要在紧凑循环中重试，那只会延长限流。如果经常发生，说明您的窗口或速率高于约定的限制。"
  - q: "如何处理数百万条送达回执？"
    a: "对每条 deliver_sm 立即用 deliver_sm_resp 应答，把回执放入队列，再异步处理并按消息 ID 存储。让处理过程具备幂等性，因为回执可能重复。回执消费者要与提交路径分开运行，并监控其积压程度。"
  - q: "可以在夜间发送促销短信吗？"
    a: "在多个市场不可以。阿联酋禁止在 21:00 至 07:00 发送营销短信，沙特阿拉伯为 22:00 至 09:00，斋月期间为 01:00 至 12:00。请按每位收件人的当地时间安排促销，并把验证码和提醒单独发送，因为它们不属于促销。"
sources: 
  - title: "SMPP Protocol Specification v3.4, SMPP Developers Forum"
    url: "https://smpp.org/SMPP_v3_4_Issue1_2.pdf"
  - title: "3GPP TS 23.040: Technical realization of the Short Message Service (SMS)"
    url: "https://www.3gpp.org/dynareport?code=23040"
  - title: "TDRA spam policy, UAE"
    url: "https://tdra.gov.ae/-/media/About/regulations-and-ruling/EN/cellular-phone-spam-regulatory-policy-English.ashx"
  - title: "CST Regulations for Curbing SPAM Messages and Calls, Saudi Arabia"
    url: "https://www.cst.gov.sa/en/regulations-and-licenses/regulations/Document-522"
---

# 每天发送数百万条短信：高并发短信发送指南

Canonical: https://omnichannels.ai/zh/blog/high-volume-sms-sending-guide/
Language: zh
Publisher: OmniChannels.ai by BroadNet Technologies

本指南写给每天发送或即将发送一百万到一千万条短信的工程师、消息运营负责人和采购团队。内容介绍如何把日发送量转换为吞吐量目标、如何配置 SMPP 绑定和窗口、如何排队和限速、如何大规模处理送达回执，以及各个国家需要提前准备什么。示例中的数字是示意性的规划数字，并不代表任何服务商的容量。

## 每天数百万条，每秒需要发送多少条短信？

您需要的是分段数除以您实际能够发送的窗口的秒数。吞吐量以 TPS（每秒提交的消息或分段数）衡量，是峰值数字，而不是日均值。参见[吞吐量（TPS）](/zh/glossary/throughput-tps/)。

先计算平均值，再计算真实发送窗口内的峰值：

| 日发送量 | 24 小时平均每秒 | 若在 4 小时内发完 | 若在 2 小时内发完 |
|---|---|---|---|
| 1,000,000 | 11.6 | 69.4 | 138.9 |
| 5,000,000 | 57.9 | 347.2 | 694.4 |
| 10,000,000 | 115.7 | 694.4 | 1,388.9 |

有两个乘数会改变这张表：

- **分段数。** 超过一个分段的消息会拆成多个部分提交，多数平台对每个部分都计数。平均 1.5 个分段的一千万条消息，就是一千五百万次提交。可通过[短信字符限制](/zh/blog/sms-character-limits-unicode-arabic/)和[字符计数器](/zh/tools/sms-character-counter/)来控制。中文属于 Unicode，一条短信只有 70 个字符，因此中文文案更容易拆成多段。
- **余量。** 加上不属于营销活动的流量，例如验证码，再为重试和运营商变慢留出余量。30% 是常见的规划余量，但不是规则。

## 如何按最忙的一小时而不是平均值来规划吞吐量？

按流量最大的时段或窗口来规划，因为那时队列会堆积，也会出现限流。使用下面的公式：

**所需 TPS =（活动分段数 ÷ 窗口秒数 + 验证码和提醒的峰值 TPS）×（1 + 余量）。**

### 案例：一家区域零售商

一家虚构的零售商一天向海湾地区的客户发送 600 万条促销消息，平均每条 1.4 个分段。它希望在允许的白天时段内用四小时发完。

- 分段数：6,000,000 × 1.4 = 8,400,000。
- 窗口：4 小时 = 14,400 秒，所以 8,400,000 ÷ 14,400 = 每秒 583 条。
- 营销活动期间验证码和提醒的峰值流量：每秒 40 条（自己的测量值）。
- 余量：30%。
- 所需：(583 + 40) × 1.3 ≈ 每秒 810 条。

零售商会在上线前要求服务商以书面形式按线路确认这个数字。它是规划输入，并不说明任何平台能承载多少。

## 什么是 SMPP 绑定？需要多少个？

SMPP 绑定是您的系统与服务商 SMSC 之间的长连接 TCP 会话，通过凭据和允许的 IP 地址进行认证。SMPP（Short Message Peer-to-Peer）是用于交换短信的电信协议，专为持续的大流量而设计。参见 [SMPP 绑定](/zh/glossary/smpp-bind/)和 [SMPP 与 REST API 对比](/zh/blog/sms-api-vs-smpp/)。

有三种绑定类型：发送端（transmitter，只提交）、接收端（receiver，只接收回执和上行）和收发端（transceiver，在一个会话中同时处理两者）。多数发送方使用收发端绑定。

需要多少个绑定：

1. 取您所需的峰值 TPS。
2. 除以服务商为您的账户约定的每个绑定的速率。
3. 向上取整，并至少增加一个备用绑定，这样断线不会使发送中断。
4. 把验证码流量放在独立的绑定或账户上。

绑定按账户开通，因此请询问数量、每个绑定的速率和允许的源 IP。我们的 [SMPP 网关](/zh/channels/sms/smpp-gateway/)页面和 [SMPP 开发者文档](/developers/smpp/)介绍了连接方式。

## SMPP 窗口是如何运作的？

窗口是您可以同时处于未完成状态的 submit_sm 请求数。SMPP 是异步的：规范说明发送方可以在不等待响应的情况下发出多个请求，并使用每个 PDU 中的 sequence_number 把响应与请求对应起来。最大未完成操作数不由规范定义，而由各方的实现决定。

根据排队算术得出的规则是：

**窗口 ≥ 目标 TPS × 往返时间（秒）。**

| 目标 TPS | 往返 50 ms | 往返 150 ms | 往返 300 ms |
|---|---|---|---|
| 100 | 5 | 15 | 30 |
| 400 | 20 | 60 | 120 |
| 810 | 41 | 122 | 243 |

窗口为 1 意味着发送方要等待每一个响应，吞吐量会被限制在 1 除以往返时间。提高窗口有助于提升速度，直到达到服务商允许的速率；超出之后只会造成限流。把这个数字当作需要与服务商协商并测试的值，而不是要最大化的值。使用多个绑定时要分摊 TPS：总计 810 TPS 的四个绑定，每个大约承载 203。

## 如何大规模排队与限速？

在应用与 SMPP 连接之间放置一个持久化队列，并用可在运行时调整的限速器来消费。队列吸收突发流量，限速器让您保持在约定的速率。

- **每个绑定、每条线路一个令牌桶。** 按约定的 TPS 补充令牌；每次 submit_sm 取一个令牌，每个分段都要计数。
- **按优先级分队列。** 先是验证码和提醒，然后是事务类，最后是促销类。
- **出错时退避。** 遇到 ESME_RTHROTTLED（0x58）或 ESME_RMSGQFUL（0x14）时暂停，然后用带抖动的指数退避重试。不要在紧凑循环中重发。
- **断线后退避重连，** 并记录未完成的序列号，以便对账哪些已被接受。
- **保持会话存活。** 规范定义了 enquire_link 计时器，用于检查对端是否仍有活动会话，还定义了空闲计时器，超时后会话可能被断开。空闲时请发送 enquire_link。
- **幂等提交。** 提交之前先保存您自己的消息 ID，这样重试就不会发送两次。

## 如何大规模按运营商路由？

除了按绑定外，也要按目标运营商排队和限速，因为一个变慢的运营商不应阻塞其他运营商。运营商可能按发送方或线路限制 A2P 流量，所以一个国家的实际限制可能低于账户速率。

1. 把每个号码解析到其运营商。号码查询有助于此；参见 [HLR 查询](/zh/blog/hlr-lookup-number-validation/)。
2. 为每个运营商或线路组保留一个队列和一个限速器。
3. 观察各运营商的送达率和回执延迟，并对变差的运营商降速。
4. 询问服务商是否使用直连线路；参见[直连线路与灰色线路](/zh/blog/grey-route-vs-direct-route-sms/)。

## 如何大规模处理送达回执？

把送达回执视为与提交一样大的第二条数据流。回执以 deliver_sm 的形式到达您的绑定，您必须用 deliver_sm_resp 应答每一条。规范在回执中定义了这些最终和中间状态：DELIVRD、EXPIRED、DELETED、UNDELIV、ACCEPTD、UNKNOWN 和 REJECTD。参见[送达回执](/zh/glossary/delivery-receipt/)和[消息送达状态详解](/zh/blog/message-delivery-status-explained/)。

一种可靠的设计：

1. **快速应答。** 回执一进入队列，就立即返回 deliver_sm_resp。
2. **异步处理，** 由工作进程按消息 ID 把回执匹配到原始消息。
3. **让处理过程具备幂等性。** 回执可能重复，也可能乱序到达。
4. **处理分段。** 视线路而定，您可能收到每个分段一条或每条消息一条回执；请测试确认。
5. **设置超时，** 对始终收不到最终状态的消息，标记为未知。
6. **让回执消费者远离提交路径，** 这样积压不会拖慢发送。

## 发送之前，每个国家需要注册什么？

各国的发送方 ID 规则不同，在某些市场，未注册的发送方会被拦截或被替换。例如：阿联酋和沙特阿拉伯要求在运营商处注册，印度要求在 DLT 上注册头部（header）和每个模板，美国则使用 10DLC 或免费号码，而不是字母数字发送方。在我们跟踪的市场中，办理周期从几个工作日到约一个月不等。

请先启动注册，因为它们在上线的关键路径上。请查看[各国短信营销规则](/zh/blog/sms-marketing-rules-by-country/)、[发送方 ID 检查器](/zh/tools/sender-id-checker/)和[阿联酋与沙特阿拉伯发送方 ID 指南](/zh/blog/sms-sender-id-registration-uae-saudi/)。我们通过[注册服务](/zh/services/registrations/)与您一起准备并提交注册；审批仍由监管机构和运营商决定。

## 大规模发送时如何遵守静默时段？

按每位收件人的当地时间和所在国家的规则安排促销，并让非促销流量不受该限制。部分市场公布了时段：阿联酋禁止在 21:00 至 07:00 发送营销短信，沙特阿拉伯为 22:00 至 09:00，斋月期间为 01:00 至 12:00。参见[静默时段](/zh/glossary/quiet-hours/)。

- 入队之前，先按国家和时区对名单分组。
- 当每组的窗口开启时，把它放入各自的队列。
- 窗口结束时停止促销队列，把剩余部分顺延到次日。
- 用[发送时间规划器](/zh/tools/send-time-planner/)规划顺序。

窗口越窄，所需的 TPS 越高，所以请把它代入规划公式。

## 为什么要把验证码和促销流量分开？

验证码和提醒对时间敏感，而促销活动是批量发送；如果它们共用一个队列或绑定，营销活动可能延误登录验证码。请使用独立的绑定或账户；规则要求时使用独立的发送方 ID；使用具有严格优先级的独立队列，以及独立的监控。验证码不属于促销，所以静默时段对其不适用。同样要保护验证码线路免遭滥用：参见[短信泵送欺诈防范](/zh/blog/sms-pumping-fraud-prevention/)和[验证码指南](/zh/blog/otp-authentication-messages-guide/)。

## 应监控哪些 KPI？

监控提交健康状况、队列时延、回执结果和回执延迟，并按国家和运营商拆分。针对您自己的基线变化设置告警。

| KPI | 公式 | 说明什么 |
|---|---|---|
| 提交成功率 | 被接受的 submit_sm_resp ÷ 已发送的 submit_sm | 绑定和账户健康度 |
| 限流率 | ESME_RTHROTTLED 响应 ÷ 已发送的 submit_sm | 速率或窗口设置过高 |
| 队列时延（p95） | 从入队到提交的时间 | 容量不足 |
| 送达率 | DELIVRD ÷ 有最终状态的消息 | 线路和内容质量 |
| 失败与过期占比 | (UNDELIV + EXPIRED + REJECTD) ÷ 最终状态 | 号码有效性、发送方 ID、过滤 |
| 回执延迟（中位数和 p95） | 回执时间 − 提交时间 | 运营商变慢 |
| 回执覆盖率 | 最终状态 ÷ 已提交的消息 | 回执缺失 |
| 退订率 | STOP 回复 ÷ 已送达的促销消息 | 受众与内容的匹配度 |

诊断方法参见[提高短信送达率](/zh/blog/sms-not-delivered-improve-delivery-rate/)。

## 数百万条群发的上线检查清单有哪些？

1. 根据分段数、窗口和验证码负载计算出所需的峰值 TPS。
2. 服务商以书面形式确认每个绑定的速率、绑定数量、窗口和源 IP。
3. 每个国家的发送方 ID 已注册，需要时已注册模板。
4. 先以一小部分流量做压力测试，再分步提升；不要一开始就用最大值。
5. 队列、限速器、退避和幂等性已测试，包括强制断线。
6. 回执管道已按全量回执做过测试。
7. 已核实各国的静默时段调度。
8. 验证码流量已分离并受到监控。
9. 看板和告警已上线，并有负责人值守。
10. 有一个能立即停止促销队列的停止按钮。

## OmniChannels.ai 如何提供帮助

BroadNet 通过运营商直连发送短信，支持基于 TLS 的 SMPP 3.4（绑定按账户开通），并提供 REST API、群发、双向短信、Unicode 和阿拉伯语、HLR 查询和送达报告。容量按账户和线路核定：告诉我们您的目的地、峰值量、发送窗口和发送方 ID，我们会与您一起确定吞吐量、绑定和注册。我们的团队负责准备发送方 ID 注册。请带着您的发送量计划[联系销售](/zh/contact/)，或了解[批发项目](/zh/partners/wholesale/)。