「Solana ShredStream 延迟持续增加」的原因与解决方案

在 ERPC，我们经常收到使用 Solana 实时数据流的客户反馈：「ShredStream 延迟逐渐增加，最终停止响应。」

本文将清晰解释此问题发生的主要原因，并提供具体的解决方案来提升您应用的性能。

为什么 ShredStream 延迟会持续增加？

目前，ShredStream 在未经过滤的情况下传输几乎所有实时数据。因此，如果客户端的处理能力不足，数据会不断积累，延迟逐渐增加。

主要原因如下：

1. 使用 Node.js 或单线程环境处理

最初，ShredStream 客户端使用 TypeScript 和 gRPC 协议构建。然而，由于过滤器尚未实现，使用 Node.js 等单线程环境很快就会达到处理上限，导致延迟持续上升。

我们确认在同一台机器上使用 Rust 客户端时不会出现此问题，从而验证了单线程处理的局限性。

解决方案：使用 NAPI-RS 实现多线程

为此，我们使用 NAPI-RS 技术开发了解决方案，在保持 TypeScript 控制的同时实现 Rust 多线程处理。该解决方案名为 Solana Stream SDK，已作为开源项目公开发布：

GitHub：ValidatorsDAO/solana-stream

如果您使用 Node.js 或 TypeScript，我们强烈推荐使用此 SDK。为获得最佳性能，建议使用 Rust 等原生多线程语言。

2. 服务器性能不足（尤其是 CPU 主频）

使用 Solana ShredStream 的实时流应用通常在 4 核 16GB RAM 的服务器上可以正常运行。但 CPU 主频极为重要。较低的主频可能导致延迟逐渐增加。

以利润为导向的服务器通常使用旧一代 CPU 或核心数多但主频低的 CPU。例如，拥有 84 核的第四代 AMD EPYC CPU 基础频率通常约为 2.2GHz，且往往无法有效利用 Turbo 加速。由于 Solana 验证者的推荐最低要求为 2.8GHz，我们强烈建议客户也采用至少达到此主频的 CPU。

此外，VPS 提供商通常使用「超额分配」，即将一台物理服务器分割为多个虚拟服务器。在超额分配的环境中，高峰时段经常与其他用户发生资源竞争，影响性能。