ZKsync 正常运行时间：监控什么以及如何保持 dApp 的弹性

快速建议：在依赖 ZKsync 之前要检查什么

在基于 ZKsync 构建之前，请确定正常运行时间对您的用例意味着什么。网络正常运行时间和 RPC 正常运行时间不是一回事。ZKsync 网络可能是健康的，而您的 RPC 提供商却宕机，反之亦然。对于生产环境的 dApp，您两者都需要。

首先检查官方的 ZKsync 状态页面以了解网络级事件。然后评估您的 RPC 提供商的冗余、故障转移和历史性能。如果您只是原型开发，公共端点可能就足够了。如果您正在服务用户，请通过多个端点和自动重试来规划提供商故障。

对于生产环境设置，请考虑像 OnFinality 这样提供专用节点和多区域故障转移的提供商。您可以在 RPC 定价 页面上比较计划，并在 支持的 RPC 网络 页面上查看支持哪些网络。

ZKsync 正常运行时间实际上意味着什么？

当人们搜索“zksync 正常运行时间”时，他们通常想知道网络是否在线。但正常运行时间有多个层面：

• 网络正常运行时间：排序器正在生成区块，网络正在处理交易。
• RPC 正常运行时间：您的端点正在响应请求而不会出错。
• 数据可用性：历史状态和日志可供您的查询访问。

网络可能正常运行，但您的 RPC 提供商可能宕机。相反，网络可能发生事件，而您提供商的缓存数据仍然可以服务一些请求。了解这些层面有助于您设计弹性。

如何检查 ZKsync 网络状态

官方的 ZKsync 状态页面是首先查看的地方。它跟踪排序器、API 和浏览器等组件。您也可以检查第三方状态聚合器，但它们可能对正常运行时间有不同的定义。

对于实时监控，您可以针对 RPC 端点设置自己的健康检查。对 eth_blockNumber 的简单 JSON-RPC 调用可以告诉您节点是否正在同步和响应。

curl -X POST https://zksync.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

如果响应返回一个区块号，则端点处于活动状态。如果超时或返回错误，则存在问题。

RPC 提供商正常运行时间：要注意什么

您的 RPC 提供商的正常运行时间至关重要。公共端点很方便，但通常有速率限制且不太可靠。对于生产环境，您需要具有以下特点的提供商：

• 冗余基础设施：跨区域的多个节点以处理故障。
• 自动故障转移：如果一个节点宕机，流量会路由到另一个节点。
• 负载均衡：分发请求以避免单个节点过载。
• 历史数据：访问归档节点以进行状态查询。

OnFinality 提供专用节点和全球 RPC 端点网络。您可以阅读更多关于 RPC 服务 和 专用节点 的信息以了解架构。

监控您自己的 ZKsync 端点

即使有可靠的提供商，您也应该监控自己的端点。设置延迟、错误率和同步状态的警报。一个简单的脚本可以检查最新区块并将其与预期时间进行比较。

const Web3 = require('web3');
const web3 = new Web3('https://zksync.api.onfinality.io/public');

async function checkSync() {
  const block = await web3.eth.getBlockNumber();
  console.log(`Latest block: ${block}`);
  // Add logic to alert if block is stale
}

setInterval(checkSync, 60000);

您也可以使用 WebSocket 进行实时更新。订阅新头部以快速检测停滞。

const ws = new WebSocket('wss://zksync.api.onfinality.io/public');
ws.onopen = () => {
  ws.send(JSON.stringify({jsonrpc: '2.0', method: 'eth_subscribe', params: ['newHeads'], id: 1}));
};
ws.onmessage = (event) => {
  console.log('New block:', JSON.parse(event.data));
};

ZKsync 中断的常见原因

ZKsync 过去曾发生过事件。例如，一个服务器错误触发了安全协议，导致区块生产停止数小时。了解常见原因有助于您做好准备：

• 排序器错误：软件错误可能停止区块生产。
• 证明器问题：ZK 证明生成可能失败或变慢。
• 基础设施故障：云提供商中断或网络问题。
• 升级：计划维护可能导致短暂停机。

虽然您无法预防网络级事件，但您可以通过使用多个 RPC 提供商并制定后备计划来减轻它们对您的 dApp 的影响。

提供商评估矩阵

在选择 ZKsync 的 RPC 提供商时，比较以下因素：

OnFinality 的基础设施专为高可用性而设计。您可以在 支持的 RPC 网络 页面上查看完整的支持网络和功能列表。

在您的 dApp 中构建弹性

即使有可靠的提供商，您也应该架构您的 dApp 以优雅地处理故障。

• 使用多个提供商：在您的 Web3 库中配置后备端点。
• 实现带退避的重试：如果请求失败，在短暂延迟后重试。
• 缓存关键数据：在本地存储最近的区块和交易。
• 监控和警报：为 RPC 健康和网络状态设置仪表板。

以下是使用 ethers.js 和后备提供商的示例：

const { ethers } = require('ethers');

const primary = new ethers.providers.JsonRpcProvider('https://zksync.api.onfinality.io/public');
const fallback = new ethers.providers.JsonRpcProvider('https://another-provider.example.com');

const provider = new ethers.providers.FallbackProvider([primary, fallback], 1);

此设置在主提供商失败时自动切换到后备提供商。

关键要点

• ZKsync 正常运行时间涉及网络健康和 RPC 提供商可靠性。
• 检查官方状态页面以了解网络事件，但也监控您自己的端点。
• 为生产环境选择具有冗余、故障转移和归档数据的 RPC 提供商。
• 通过多个提供商和重试逻辑在您的 dApp 中构建弹性。
• OnFinality 为 ZKsync 和其他网络提供强大的基础设施；请参阅 RPC 定价 和 支持的网络。

常见问题解答

问：如何检查 ZKsync 正常运行时间？

答：访问官方的 ZKsync 状态页面，或使用 JSON-RPC 调用 eth_blockNumber 来检查网络是否响应。

问：网络正常运行时间和 RPC 正常运行时间有什么区别？

答：网络正常运行时间指的是排序器和网络处理交易。RPC 正常运行时间指的是您的端点响应请求的能力。两者都很重要。

问：我可以依赖公共 RPC 端点用于生产环境吗？

答：公共端点通常有速率限制且不太可靠。对于生产环境，请考虑专用节点或具有 SLA 的提供商。

问：如果 ZKsync 发生中断，我该怎么办？

答：准备一个后备提供商并实现重试逻辑。监控状态页面以获取更新，并与您的用户沟通。

问：OnFinality 支持 ZKsync 吗？

答：是的，OnFinality 支持 ZKsync 主网和测试网。请参阅 ZKsync 网络页面 了解详情。