Высокопроизводительная потоковая передача данных Solana с SDK LaserStream 

Надежная потоковая передача благодаря переподключению и воспроизведению данных

Все три SDK LaserStream — JavaScript/TypeScript, Rust и Go — решают критически важную задачу высокоскоростной потоковой передачи: сохраняют непрерывность данных при сбоях сети.

Каждый SDK автоматически переподключается и отслеживает слоты. При разрыве соединения клиент сохраняет номер последнего обработанного слота.

После переподключения он продолжает работу с этой точки, запрашивая воспроизведение исторических данных за период до 48 часов.

Такая архитектура предотвращает потерю данных при временных разрывах соединения на стороне сервера и не требует логики повторных попыток на уровне приложения.

Трекер слотов хранит номера обработанных слотов в памяти. Если используется replay: true (значение по умолчанию), SDK гарантирует отсутствие пропусков в потоке данных. Некоторые конфигурации, особенно выделенные ноды, не поддерживают воспроизведение исторических данных. Для таких эндпоинтов задайте replay: false, чтобы отключить внутреннее отслеживание слотов и после переподключения продолжить работу с текущего слота.

Узкие места производительности JavaScript в потоках gRPC

Потоки gRPC в Node.js сталкиваются с практическими ограничениями, которые становятся критическими при высокой нагрузке. Это не теоретическая проблема. Она проявляется, когда callback-функция обрабатывает каждое сообщение.

Из-за однопоточного цикла событий JavaScript каждая операция в обработчике данных (например, разбор JSON, проверка данных, выполнение бизнес-логики или журналирование событий) блокирует последующие сообщения.

Если сообщения поступают быстрее, чем обработчик успевает их обрабатывать, поток начинает отставать, растет обратное давление, callback-функции накапливаются в очереди, а приложение обрабатывает все более устаревшие данные.

Чистые JS-клиенты gRPC создают дополнительную нагрузку: 

• Десериализация protobuf в JavaScript
• Повышенная нагрузка на сборщик мусора из-за выделения памяти под объекты
• Многократное пересечение границы между JavaScript и нативным кодом при сетевом вводе-выводе

Для приложений, обрабатывающих тысячи обновлений аккаунтов или уведомлений о транзакциях в секунду, таких как MEV-инфраструктура, аналитика в реальном времени или отслеживание книги ордеров, эти задержки сводят на нет любые конкурентные преимущества. Ваши системы реагируют на события, произошедшие несколько секунд назад.

Оптимизация производительности JavaScript SDK с помощью ядра на Rust и NAPI-привязок без копирования

JavaScript SDK LaserStream устраняет эти узкие места, полностью перенося ресурсоемкие операции из JavaScript.

Весь движок потоковой передачи, управление соединением gRPC, сериализация protobuf и отслеживание слотов работают на Rust. В JavaScript выполняется только логика вашего приложения.

Такая архитектура решает основные проблемы: 

1. Сетевой ввод-вывод и десериализация protobuf не затрагивают цикл событий JavaScript.
2. Уровень Rust обрабатывает все сообщения в отдельных потоках.
3. Уровень Rust передает предварительно сериализованные байты protobuf в callback-функции JavaScript через привязки NAPI (Node-API).

Вот схема работы JavaScript SDK LaserStream:

Привязки NAPI обеспечивают передачу обновлений без копирования данных. Когда LaserStream отправляет сообщение protobuf, уровень Rust десериализует его, при необходимости отслеживает слот, а затем напрямую передает необработанные байты в JavaScript как Uint8Array — без дополнительной сериализации и промежуточного копирования.

Разница в производительности огромна: 1.3 GB/s против 30 MB/s — в 40 раз быстрее, чем у стандартных JavaScript-клиентов Yellowstone. 

Это не постепенное улучшение. Это разница между обработкой полных потоков блоков в реальном времени и отставанием на несколько минут.

Ядро на Rust отвечает за:

• Жизненный цикл соединения gRPC и управление потоком
• Автоматическое переподключение с экспоненциальной задержкой
• Отслеживание слотов и логику воспроизведения данных
• Кодирование и декодирование protobuf
• Потокобезопасный вызов callback-функций через ограниченные очереди, предотвращающий чрезмерное потребление памяти при замедлении callback-функций

JavaScript выполняет логику приложения, фильтрацию, бизнес-правила и сохранение данных, не сталкиваясь с узкими местами сетевого ввода-вывода или сериализации.

Поддержка сжатия

LaserStream поддерживает несколько алгоритмов сжатия на транспортном уровне gRPC. По сравнению с несжатыми потоками Zstd сокращает использование пропускной способности на 70–80%. Это критически важно для высоконагруженных подписок, где исходящий трафик растет линейно с объемом передаваемых данных.

Настроить сжатие просто:

const config = {
  apiKey: 'your-key',
  endpoint: 'your-endpoint',
  channelOptions: {
    'grpc.default_compression_algorithm': CompressionAlgorithms.zstd,
    'grpc.max_receive_message_length': 1_000_000_000,
  }
};

Zstd обеспечивает более высокую степень сжатия, чем gzip, при сопоставимой нагрузке на CPU, поэтому мы рекомендуем использовать его.

Заключение

SDK LaserStream решают фундаментальные проблемы высокопроизводительной потоковой передачи данных. Они сохраняют совместимость с Yellowstone и добавляют отсутствующие в стандартных клиентах функции надежности, автоматическое переподключение и воспроизведение данных по слотам. 

В JS-приложениях архитектура на базе Rust устраняет узкие места цикла событий, из-за которых чистые реализации на JS непрактичны при масштабировании.

Увеличение пропускной способности в 40 раз — не постепенная оптимизация. Это архитектурное отличие между обработкой полных потоков блоков в реальном времени и отставанием на несколько минут при экстремальной нагрузке.

Для production-приложений, где задержка и надежность критически важны, — MEV-инфраструктуры, аналитики в реальном времени и автоматизированных торговых систем — SDK LaserStream обеспечивают необходимую основу.

Дополнительные ресурсы

• Документация LaserStream
• SDK Laserstream (GitHub)