PublicNode 速率限制：预期与规划指南

快速建议：何时 PublicNode 足够，何时不够

PublicNode 是一个免费的、面向社区的 RPC 服务，支持数十条链。对于原型开发、黑客马拉松和低流量 dApp，它可以是一个合理的起点。但由于它是免费且共享的，它应用了通常不会详细公布的速率限制。如果你的应用需要一致的吞吐量、WebSocket 订阅或归档数据，你应该为这些限制做好规划，并有一个后备方案。

以下是一个快速决策路径：

• 在以下情况下使用 PublicNode： 开发、测试、小型个人项目，以及偶尔限流可接受的非关键读取调用。
• 在以下情况下迁移到专用或商业 RPC 提供商： 你处于生产环境，需要可预测的性能，依赖 WebSocket 获取实时数据，或需要归档/跟踪数据。
• 始终有后备方案： 即使你留在 PublicNode，也要配置一个辅助 RPC 端点，以便你的应用能够优雅地故障转移。

如果你正在评估提供商，请比较速率限制、定价和网络覆盖。OnFinality 提供 RPC 定价，具有透明的层级，并支持广泛的 网络。

PublicNode 速率限制通常如何工作

PublicNode 没有发布一个统一的速率限制。像大多数免费 RPC 服务一样，限制是按 IP 地址应用的，并且可能因链和端点类型（HTTP 与 WebSocket）而异。具体数字可能会在没有通知的情况下更改，因此你应该将它们视为“尽力而为”，并设计你的应用来处理限流。

免费 RPC 服务的常见模式包括：

• 每秒请求数（RPS）： 从单个 IP 每秒可以发送的请求数量上限。
• 时间窗口内的请求数： 例如，每分钟或每小时的最大请求数。
• 并发连接数： 可以打开的并发 WebSocket 连接数量限制。
• 基于方法的限制： 一些重方法（如 eth_getLogs 或 trace_*）可能有更严格的限制。

当你超过限制时，服务器通常会响应 HTTP 429（请求过多）或 JSON-RPC 错误。你的客户端库也可能遇到超时或连接重置。

检测速率限制：症状和诊断步骤

如果你的应用开始间歇性失败，速率限制是一个可能的罪魁祸首。以下是常见症状以及如何确认它们：

• HTTP 429 响应： 最明显的迹象。检查你的客户端日志中的状态码 429。
• JSON-RPC 错误： 一些提供商返回一个错误对象，消息如“rate limit exceeded”或“too many requests”。
• 超时： 如果请求挂起然后失败，你可能遇到了连接限制。
• WebSocket 断开： 频繁断开或无法订阅可能表明连接限制。

要诊断，请从你的服务器 IP 运行一个简单的负载测试。例如，使用 curl 发送一批请求：

for i in $(seq 1 100); do
  curl -s -o /dev/null -w "%{http_code}\n" \
    -X POST https://rpc.publicnode.com \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
done | sort | uniq -c

如果你看到大量 429 响应，说明你已经达到了限制。你还可以监控响应时间；突然的峰值通常表明限流。

将 PublicNode 与其他免费和付费 RPC 选项进行比较

在选择 RPC 提供商时，你不仅仅是在比较价格——你还在比较可靠性、功能和支持。以下是一个实用的比较表：

对于生产应用，缺乏文档化的速率限制和正常运行时间保证是一个风险。像 OnFinality 这样的商业提供商提供可预测的限制和支持。请参阅我们的 RPC 定价 了解详情。

如何在你的应用中处理速率限制

即使你留在 PublicNode，你也可以通过客户端策略来减少速率限制的影响：

• 实现指数退避重试： 当你收到 429 时，等待并重试。
• 缓存响应： 对于读取密集型数据（如代币价格或区块号），缓存以减少请求量。
• 批量请求： 使用 JSON-RPC 批处理在一次 HTTP 请求中发送多个调用。
• 谨慎使用 WebSocket： 如果你需要实时数据，请考虑使用专用提供商进行 WebSocket 连接。

以下是一个使用 fetch 的简单重试示例（JavaScript）：

async function rpcCall(url, method, params, retries = 3) {
  for (let i = 0; i < retries; i++) {
    const res = await fetch(url, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ jsonrpc: '2.0', method, params, id: 1 })
    });
    if (res.status === 429) {
      const delay = Math.pow(2, i) * 1000;
      await new Promise(resolve => setTimeout(resolve, delay));
      continue;
    }
    return res.json();
  }
  throw new Error('Rate limited after retries');
}

何时升级：你已超出 PublicNode 的迹象

以下是一些明确的信号，表明是时候迁移到专用或商业 RPC 提供商了：

• 你的应用处于生产环境： 免费端点并非为生产流量设计。
• 你经常看到 429： 你的用户群在增长，限制太紧。
• 你需要 WebSocket 可靠性： 对于交易应用或实时仪表板，连接断开是不可接受的。
• 你需要归档数据： 历史状态查询通常不受免费端点支持。
• 你需要支持渠道： 如果你的应用宕机，你需要有人可以联系。

当你升级时，你会希望提供商提供：

• 文档化的速率限制和公平使用政策。
• 多个端点用于故障转移。
• WebSocket 和归档支持。
• 透明的定价。

OnFinality 的 专用节点 服务为你提供隔离的资源，而我们的 共享 RPC 在成本和可靠性之间提供了平衡。

迁移清单：从 PublicNode 迁移到专用 RPC

如果你决定迁移，以下是一个清单，使过渡顺利：

1. 评估你的使用情况： 测量你当前的请求量和使用的方法。
2. 选择提供商： 比较功能和定价。OnFinality 支持许多 网络。
3. 设置你的新端点： 创建 API 密钥并获取你的端点 URL。
4. 更新你的应用配置： 将 PublicNode URL 替换为你的新端点。
5. 彻底测试： 运行你的测试套件并监控错误。
6. 实现故障转移： 保留 PublicNode 作为备份或使用多个端点。
7. 监控性能： 迁移后跟踪延迟和错误率。

以下是一个更新钱包或 dApp 配置的示例：

// 之前
const RPC_URL = 'https://rpc.publicnode.com';

// 之后
const RPC_URL = 'https://your-endpoint.onfinality.io';

关键要点

• PublicNode 速率限制是真实存在的，但并不总是有文档；将它们视为尽力而为。
• 通过观察 429、超时和 WebSocket 断开来检测限制。
• 使用客户端策略（如重试和缓存）来减轻限流。
• 对于生产环境，选择具有文档化限制和支持的提供商。
• 始终有一个后备 RPC 端点以确保正常运行时间。

常见问题解答

PublicNode 的速率限制是多少？

PublicNode 没有发布统一的速率限制。限制因链和端点类型而异，通常按 IP 地址应用。当你超过限制时，你可能会看到 429 响应。

PublicNode 是免费的吗？

是的，PublicNode 为许多区块链提供免费的 RPC 端点。然而，免费服务通常有更严格的速率限制，并且没有正常运行时间保证。

我可以将 PublicNode 用于生产应用吗？

不建议。免费的公共端点是共享的并且有速率限制，这可能导致停机或性能问题。对于生产环境，请考虑像 OnFinality 这样的商业 RPC 提供商。

我如何知道我是否被限流了？

查找 HTTP 429 响应、提到速率限制的 JSON-RPC 错误，或突然的超时。你也可以运行负载测试来查看限制何时生效。

如果我遇到 PublicNode 的速率限制，我该怎么办？

实现带退避的重试、缓存响应，并减少请求量。如果你持续遇到限制，请升级到专用 RPC 提供商。