---
title: "零停机、零间隙：我们如何构建容错的 Solana gRPC 流"
description: "多节点冗余、shred 摄取与 Richat——我们如何为不能容忍间隙或峰值的团队设计 Solana gRPC 流架构。"
---

# 零停机、零间隙：我们如何构建容错的 Solana gRPC 流

<ImageBlock
  src="https://media.alchemy.com/blog/solana-grpc-deep-dive-banner.png"
  alt="Solana gRPC 深度解析——容错流式传输横幅"
  width={1024}
  height={480}
  priority
/>

对于构建交易基础设施、MEV 搜索、清算机器人和实时索引器的团队来说,产品的速度取决于输入数据的速度。数据流出现峰值或中断,就意味着漏掉一笔交易或索引不完整。

这就是我们在多节点冗余层之上构建 [Solana gRPC streaming product](https://www.alchemy.com/solana-grpc) 的原因:峰值和中断会在到达你的数据管道之前被吸收,你不需要在一个本应是托管服务的东西之上自己搭建故障转移逻辑。下面是我们的架构设计方式。

## 为什么 gRPC 在 Solana 上很重要

Solana 的数据输出量巨大:峰值速度下每年超过 4 PB。通过 JSON-RPC 进行传统轮询会带来不必要的开销——重复请求、带宽浪费,以及请求-响应周期本身固有的延迟。对于需要在账户更新或交易被确认的那一刻就获取数据的负载来说,轮询无法胜任。

基于 Protobuf/HTTP2 的 gRPC 流式传输颠覆了这一模式。服务器在数据产生时就将其推送给客户端。构建者可以准确订阅自己需要的数据——特定账户、程序、交易模式——并接收一个持续的、经过过滤的数据流,没有轮询延迟。对于区块时间在亚秒级、数据量庞大的 Solana 来说,这是那些需要向用户提供最新数据的应用的理想方案。

Yellowstone gRPC 接口已经成为 Solana 流式传输的事实标准。构建者可以使用 Rust、TypeScript、Go 以及任何能编译 `.proto` 文件的语言的现有客户端库。我们采用了这一标准,因此从任何兼容 Yellowstone 的提供商迁移,只需修改一个 URL,而不需要重写代码。

## 架构:从 shred 到流

我们的流式传输管道有四层,每一层都内置了冗余设计,以保证大规模场景下的可靠性能。

### Shred 摄取

Shred 是 Solana 上数据传播的基本单位——大小符合 MTU(约 1,280 字节)的帧,包含区块条目的片段。网络通过 Turbine 广播 shred,这是一种多跳协议,验证者通过分层的"邻域"relay 数据。Turbine 速度很快,但它是概率性的。丢包会随跳数累积,树中较深的节点在组装出完整区块之前,可能需要等待数百毫秒的间隙修复(gap repair)。

我们同时从多个独立来源摄取 shred——包括直接从高权益验证者收集 shred 的服务,从而绕过 Turbine 的多跳延迟。每个来源覆盖不同的地理路径和验证者邻域。一个数据流中的缺口会被另一个数据流填补,这意味着更快的区块组装和更少的修复周期。

这很重要,因为一个节点需要最少数量的 shred 才能组装出每个 slot。如果它在大约 250 毫秒内没有收到足够的 shred,就会回退到修复协议——向对等节点请求缺失的 shred,这会带来明显的延迟。在修复触发之前尽快凑齐足够的 shred 至关重要。这就是我们从多个独立来源摄取数据的原因:更多的覆盖面意味着节点更快达到阈值,更早组装出条目,也更早触发 Geyser 通知。这里节省下的每一毫秒都会向下游层层传递。

### Richat 引擎

我们流式传输服务的核心是 Richat,一个作为 Geyser 插件运行在 Solana 节点上的开源引擎。它捕获账户更新、交易通知、slot 状态、区块元数据和条目更新——这些都是 Agave 客户端产生的,然后将它们流式传输到 Richat 服务器,后者充当聚合与分发层。

关键的设计决策是:每个 Richat 服务器同时连接多个上游 Solana 节点。它对来自不同来源的更新去重,并向下游提供最快的健康结果。当某个上游节点在某个 slot 上落后时,聚合层会改用下一个最快节点的数据。

这正是我们实现延迟峰值削减的原因。单节点部署在 p99 和 p999 延迟上会有很长的尾部,因为上游节点的每一次异常都会直接传递给每一个消费者。多节点聚合压平了这条尾部——构建者收到的数据流始终反映当下表现最好的那个节点,而不是唯一的那个节点。

### 构建者的数据流

构建者可以使用标准的 Yellowstone 客户端库进行连接。连接后,他们可以订阅账户更新(支持 program、owner 和 data-slice 过滤器)、交易更新(支持 account-include/exclude 和签名过滤器),以及 slot、block、block-meta 和 entry 更新。承诺级别(`processed`、`confirmed`、`finalized`)、Zstd 压缩和服务端 keepalive 均原生支持。

在同一个连接上可以用 AND/OR 语义组合多个并发订阅。双向流让构建者无需重新连接即可订阅、修改和取消订阅。

### 重连后的重放

短暂断连和客户端重启是不可避免的。问题在于,这些中断是否会造成数据丢失。

我们在 Richat 的环形缓冲区中存储一个滚动窗口的近期更新。客户端重连时,可以带上 `from_slot` 参数订阅,先回填错过的所有数据,再衔接上实时数据流。不需要单独的回填管道,不需要维护缺口检测逻辑,也不需要在消费者旁边运行协调服务。

对于需要在长时间跨度内保持无缺口数据流的构建者——索引器、分析平台,以及任何运行有状态消费者、不能承受漏掉更新的场景——这是一种更简单的运维模式。

## 接下来

当前的架构是基础,而不是上限。我们正在推进以下工作:

**扩展重放窗口。** 大幅扩大重连回填窗口,满足需要更长恢复覆盖范围的构建者的需求。

**硬件与网络优化。** 持续进行基础设施改进,以降低关键路径上的延迟。

**新增区域。** 扩大覆盖范围,让数据流更靠近更多构建者和更多验证者。

**专用部署。** 面向少数将同地部署和隔离视为硬性要求(而非可选偏好)的团队。

## 开始使用

[Alchemy Solana gRPC](https://www.alchemy.com/solana-grpc) 现已在所有付费方案中开放,起价为每 TB 75 美元,没有方案门槛,也没有月度最低消费。如果你已经在运行 Yellowstone 客户端,迁移只需修改一个 URL。

- [阅读文档](https://www.alchemy.com/docs/reference/yellowstone-grpc-quickstart)
- [联系我们团队](https://www.alchemy.com/contact-sales)
- [申请 2000 万美元 Solana Fund](https://www.alchemy.com/solana-20m-fund),最高可获得 2.5 万美元额度,加速你的应用在 Solana 上的发展。