性能指南：速率限制与突发限制注意事项

Cobre 的公共 API 在稳定状态下支持 每秒 30 笔交易（TPS）。为确保稳定的性能并避免 HTTP 429 (Too Many Requests) 错误，我们强烈建议遵循以下 API 最佳实践：

实现带有重试逻辑的指数退避机制。

在所有敏感操作中使用幂等键。

避免激进的轮询模式。

在适用情况下优化请求频率并采用批量处理。

尽可能依赖 Webhook 获取异步更新。

高效使用 API 有助于保持低延迟、高可靠性和可预测的行为——即使在流量高峰期间也不例外。

除持续速率限制外，每个客户端的 API 密钥还设有 200 个请求的突发限制，该限制通过令牌桶算法实现。令牌桶最多可容纳 200 个令牌（每个请求消耗一个），并以每秒 30 个令牌的速率进行补充——与稳定状态下的速率限制保持一致。

这意味着：

200 个请求的容量是一次性缓冲区，而非每秒可重复使用的上限。一旦耗尽，仅以 30 个令牌/秒的速度补充，因此持续超过 30 TPS 的流量将耗尽令牌桶，最终触发 HTTP 429 响应。

例如：若在令牌桶满时于第一秒内发送 100 个请求，则 100 个请求全部成功，令牌桶补充 30 个（此时为 130/200）。但若持续以每秒 50 个请求的速度发送，200 个令牌的缓冲区将在数秒内耗尽，此后超出部分的请求将被限速至 30 TPS 的补充速率，直到请求量恢复正常。

重要提示： 由于同一客户端下的所有凭据共享同一个底层 API 密钥，创建多个凭据（例如用于不同服务或使用场景）不会提高可用吞吐量。

为避免因突发流量导致的限速，我们建议：

平滑请求分布 — 将请求均匀分散在时间轴上，而非集中以大批量发送。

在客户端实现令牌桶或漏桶算法 — 这些模式可在遵守速率边界的同时自然吸收突发流量。

主动监控 429 响应 — 将其视为立即降速的信号，并以指数退避方式进行重试。

避免同步重试 — 若多个进程在失败后同时重试，可能会放大突发效应。请为重试间隔添加随机抖动（jitter）。