跳转到主要内容

速率限制

速率限制定义了应用程序在指定时间段内可以向 API 发出的最大请求数。该机制对于维护服务的整体健康性和可靠性至关重要。

为什么使用速率限制​

API 稳定性与性能
  • 防止单个客户端以过多请求压垮服务器。
  • 确保所有客户端获得一致且可预测的响应时间。
  • 保护后端服务免受意外流量峰值的冲击。
  • 在基础设施上维持稳定、可控的负载模式。
安全性
  • 加强对攻击尝试（如暴力破解）的防御。
  • 降低分布式拒绝服务（DDoS）攻击的风险。
  • 减少由实现不佳的集成所造成的影响。
  • 限制 API 凭证泄露后可能造成的潜在损害。
资源分配
  • 确保所有客户端对 API 资源的均衡访问。
  • 防止少数用户的滥用行为降低其他用户的体验。
  • 允许根据业务标准和需求对流量进行优先排序。
  • 鼓励更高效、更可持续的 API 使用实践。

速率限制的工作原理​

每次 API 调用都会计入允许的每秒请求数限制。默认值为每个租户 10 RPS。超出限制时，API 将返回 HTTP 429 Too Many Requests。

请向您的入驻团队确认

确切的限制按租户配置。在为高吞吐量集成进行规模估算之前，请联系您的入驻团队以确认适用于您账户的限制。

处理 429 错误​

申请提高速率限制

如果您的操作将出现请求量增加（临时或永久），请通知 Unico 团队为您的环境提高速率限制。此申请应在请求量实际增加之前提出，以避免您的应用程序停止运行。

审查应用程序行为
  • 审计您的代码以识别低效的 API 使用模式。
  • 检查是否存在无意的循环或冗余的 API 调用。
  • 将请求更均匀地分散到时间轴上，而不是以大批量突发方式发送。
实现缓存
  • 缓存不经常变化的频繁访问数据。
  • 在整个 1 小时 TTL 内使用 OAuth2 访问令牌——不要在每次请求时调用 POST /oauth2/token。
  • 实施适当的缓存失效策略。
使用 Webhook 替代轮询

订阅 Webhook 和事件 的 PROCESS_STATE_FINISHED 事件，而不是轮询 GET /client/v1/process/\{id\}。在高流量情况下，轮询循环很容易耗尽 GET process 的配额。

触达限制时会发生什么​

平台将返回：

HTTP/1.1 429 Too Many Requests
Retry-After: 12
响应头含义
Retry-After重试前需要等待的秒数。请遵守此值。

如果 Retry-After 缺失，则采用指数退避策略（1s、2s、4s、8s……），上限为 60s。

并发注意事项​

速率限制限制每分钟的请求数，但平台在基础设施层面也有并发上限。即使您有 100 次/分钟的配额，在同一秒内同时发出 100 个请求也比将其分散到整个分钟内更容易被拒绝。

对于高吞吐量集成，请以稳定的 RPS 为目标，而不是突发式发送。

Trully 对 Webhook V2 有自己的投递配额。Webhook 服务器预计应在 1 分钟内响应；响应更慢的请求将被丢弃（用户的流程不受影响）。为确保一致的处理，请快速确认 Webhook 并异步处理。

下一步​

最后更新 于