概述
推送限流控制 OneSignal 投递推送通知的速率。使用限流将投递分散到不同时间——防止服务器过载、避免批量发送期间的性能下降,并在各设备间保持一致的用户体验。为什么推送发送会影响您的服务器
向大量受众发送推送通知可能会在您自己的服务器上产生突然的流量峰值——即使您的点击率很低。这是因为投递本身(而不仅仅是点击)会触发多种类型的回到您基础设施的请求。了解这些来源有助于您选择正确的缓解策略。自托管图像和媒体
当推送通知包含图像(例如big_picture 或 chrome_web_image)时,收到通知的每台设备在投递时立即下载该图像。如果图像托管在您自己的服务器而不是 CDN 上,这会为每条已投递的通知创建一个 HTTP 请求——可能在数秒内产生数万个请求。
建议:
- 将通知图像托管在 CDN 上(如 CloudFront、Cloudflare、Fastly),而不是您的应用服务器。
- 如果必须自托管媒体,请使用推送限流将投递分散到不同时间。
同时打开应用
推送投递会促使许多用户同时打开您的应用。每次应用打开通常会对您的后端产生多个请求:会话初始化、内容获取、API 调用和分析事件。即使适度的打开率,如果同时投递数千条通知,也可能转化为显著的流量峰值。 建议:- 使用推送限流错开投递,将应用打开分散到更宽的时间窗口。
- 确保您的后端能够处理高容量发送的突发流量,或使用自动扩展基础设施。
Event Streams
如果您配置了Event Streams并使用 webhook 目标,OneSignal 会为每个事件(如message.sent、message.delivered、message.clicked)实时向您的端点发送 HTTP 请求。在大规模推送发送期间,这可能会产生与受众规模成比例的 webhook 请求突发。
OneSignal 不对出站 Event Stream webhook 流量进行速率限制。您的端点必须能够处理消息发送产生的事件量。
- 确保您的 webhook 端点能够处理与受众规模成比例的吞吐量。
- 使用中间队列或缓冲区(如 Amazon Kinesis、Google Pub/Sub)而不是直接 webhook 来吸收突发流量。Event Streams 本机支持这些作为目标。
- 使用推送限流降低到达端点的事件峰值速率。
Journey webhooks
Journey webhooks 在用户到达 Journey 中的特定步骤时向您的服务器发送 HTTP 请求。虽然 Journey 根据用户行为自然调节投递节奏,但高流量的 Journey 仍然可能产生大量 webhook 调用量。响应慢或过载的端点可能触发自动禁用 webhook。 建议:- 将您的 webhook 端点设计为快速响应(返回
200 OK),并将繁重处理推迟到后台作业。 - 监控来自端点的
429响应,这可能触发 OneSignal 禁用 webhook。 - 查看 Journey webhooks 文档中的性能指南。
Service Worker 获取(web push)
对于 web push,浏览器会定期从您的服务器重新获取 OneSignal Service Worker 文件(通常在缓存过期时,最多每 24 小时一次)。当推送通知被投递时,浏览器可能会检查是否有更新的 Service Worker 文件——为每个 web push 订阅生成一个回到您托管服务器的请求。 建议:- 从 CDN 提供
OneSignalSDKWorker.js文件,或确保您的托管服务器能够处理请求量。 - 设置适当的缓存头以减少重新获取频率。
- 有关更多详细信息,请参阅 OneSignal Service Worker 文档。
选择正确的方法
| 流量来源 | 受限流影响? | 替代缓解方法 |
|---|---|---|
| 自托管图像 | 是——较慢投递 = 较少并发下载 | 托管在 CDN 上 |
| 同时打开应用 | 是——错开投递分散用户会话 | 自动扩展基础设施 |
| Event Streams(webhooks) | 是——较慢投递 = 较低事件速率 | 使用基于队列的目标(Kinesis、Pub/Sub 等) |
| Journey webhooks | 否——Journey 不支持限流 | 优化端点性能;使用后台处理 |
| Service Worker 获取 | 是——较慢投递 = 较少并发获取 | CDN 托管;缓存头 |
配置选项
必须在全局设置级别启用限流才能使用此功能。全局限流设置
在 Settings > Push & In-App > Throttling 下为所有推送消息启用限流。启用后,此设置默认适用于所有推送通知,但可以为单个消息进行重写。
按消息限流重写
您可以在单个消息上重写全局限流设置。- 在创建通知期间,选中”Override throttling setting”框
- 设置您所需的每分钟消息数量
- 要为特定消息禁用限流,请在每分钟消息字段中输入”0”
throttle_rate_per_minute 属性。
限流如何工作
速率转换过程
OneSignal 将您的每分钟设置转换为每秒速率以优化投递:- 系统将您的限流速率除以 60(每分钟秒数)
- 结果向下舍入到最接近的整数(OneSignal 无法发送部分消息)
- 然后在整个投递过程中应用此每秒速率
- OneSignal 除以 60:1,019 ÷ 60 = 16.98 条消息每秒
- 向下舍入为 16 条消息每秒
- 实际投递速率:16 × 60 = 960 条消息每分钟(比设置速率少 59 条)
限制和注意事项
24 小时投递窗口
所有限流通知必须在发送后 24 小时内完成投递。如果您的限流速率会导致投递超过 24 小时,OneSignal 会自动调整速率以确保在此时间范围内完成投递。 示例: 您为 20,000 个用户设置 10 条消息每分钟的限流速率——投递大约需要 33 小时。OneSignal 会自动将速率调整为约 14 条消息每分钟,以在 24 小时内完成投递。兼容性与可用性
限流仅适用于通过创建通知 API 或 Messages > New Push 仪表板界面发送的推送通知。Journey 和自动化消息不支持限流(请参阅上方的汇总表)。时区和智能投递
限流优先于时区和智能投递。启用限流时,OneSignal 会忽略该通知的这些功能。 要使用时区或智能投递:- 在投递计划下为该特定通知禁用限流
- 将”Override throttling setting”设置为”0”
- 对于 API 通知,设置
throttle_rate_per_minute: 0
常见问题
限流是否适用于智能投递或时区投递?
否。限流优先于智能投递和时区投递。为通知启用限流时,OneSignal 会忽略这些计划功能。要使用智能投递或时区投递,请将该通知的限流覆盖设置为0。
如果我的限流速率会超过 24 小时会怎样?
OneSignal 会自动提高限流速率以确保投递在 24 小时内完成。例如,以每分钟 10 条消息向 20,000 个用户发送需要约 33 小时,因此 OneSignal 会将速率调整为约每分钟 14 条消息。我可以对 Journey 或自动化消息进行限流吗?
否。限流仅适用于通过仪表板(Messages > New Push)或创建通知 API 发送的推送通知。Journey 和自动化消息在用户符合条件时动态投递,这自然地将投递分散到不同时间。为什么我的实际投递速率低于我设置的速率?
OneSignal 将您的每分钟速率转换为每秒速率并向下舍入。例如,每分钟 1,019 条消息变为每秒 16 条消息(1,019 ÷ 60 = 16.98,向下舍入),实际速率为每分钟 960 条消息。相关页面
推送概述
使用 OneSignal 发送和管理移动及 web 推送通知。
创建通知 API
创建和发送通知的 API 参考,包括
throttle_rate_per_minute 属性。Event Streams
将投递和互动事件流式传输到 webhooks、Kinesis 或 Pub/Sub。
OneSignal Service Worker
配置 web 推送通知的 Service Worker 文件。
Journey 概述
构建响应用户操作的多步骤消息工作流。