С первого взгляда
| Возможность | v1 | v2 |
|---|---|---|
| Поток транзакций в реальном времени | ||
Фильтры аккаунтов include / exclude / required | ||
| Проверки ping и версии | ||
| Изменение фильтров на лету, без переподключения | ||
| Именованные фильтры с подтверждениями принятия / отклонения | ||
| Обогащённые поля транзакции (плательщик комиссии, цена вычислительной единицы, лимит вычислительных единиц, идентификаторы программ, записываемые аккаунты, размер) | ||
| Разрешённые аккаунты из таблиц поиска адресов | ||
| Поток жизненного цикла слотов (alive / complete / dead) | ||
| Номера последовательности в каждом сообщении для обнаружения пропусков | ||
| Heartbeat-сообщения при простое |
И v1, и v2 дают вам декодированную транзакцию: подписи, ключи аккаунтов, инструкции, заголовок
сообщения и любые ссылки на таблицы поиска адресов. То, что v2 добавляет, — это обогащение
поверх этого (предварительно вычисленные поля выше), плюс возможности живой подписки, слотов и
контроля живости. Обогащение опционально; см. ниже.
Больше данных, меньше RPC-вызовов
С v1 вы получаете декодированную транзакцию и вычисляете остальное сами. Всё, что за пределами основных полей, — на вас: кто оплатил комиссию, какую цену вычислительной единицы она установила, какие аккаунты записываемые и какие реальные аккаунты стоят за таблицами поиска версионной транзакции. v2 может выполнить эту работу за вас. Включите обогащение, и каждая транзакция также будет нести поля ниже.| Чтобы получить… | В v1 вы… | В v2 (обогащение включено) |
|---|---|---|
| Полный список аккаунтов версионной (v0) транзакции | Делаете полный RPC-вызов на каждую транзакцию, чтобы получить таблицу поиска, а затем сами разрешаете индексы | Уже разрешено и включено (loaded_writable_addresses / loaded_readonly_addresses) |
| Плательщик комиссии | Выводите его из ключей аккаунтов и заголовка | Включён (fee_payer) |
| Цена вычислительной единицы и лимит вычислительных единиц | Сами разбираете инструкции compute-budget | Включены (compute_unit_price, compute_limit) |
| Записываемые аккаунты | Вычисляете их из заголовка и разрешённых таблиц поиска | Включены (writable_accounts) |
| Идентификаторы программ, которых касается транзакция | Обходите каждую инструкцию | Включены (program_ids) |
| Размер транзакции | Реконструируете и измеряете транзакцию | Включён (tx_size) |
compute_unit_price — это цена вычислительной единицы, значение микро-лампортов на CU из
SetComputeUnitPrice, а не общая приоритетная комиссия. Чтобы получить общую приоритетную комиссию
в лампортах, умножьте на лимит вычислительных единиц и разделите на 1 000 000:
compute_unit_price × compute_limit / 1e6. compute_limit отражает только явный
SetComputeUnitLimit (0, если транзакция его не задаёт).Для версионной транзакции разрешённые адреса из таблиц поиска включены. Если какие-то из них не
могут быть полностью включены, для этой транзакции устанавливается
alt_resolution_incomplete,
чтобы вы разрешили их сами (получив таблицы через RPC) — никаких скрытых пропусков.Обогащение опционально и по умолчанию выключено. Включайте его для каждой подписки
(
include_enrichment: true в фильтре), когда вам нужны дополнительные поля — его включение не
добавляет задержки потоку; единственное отличие — умеренно больший размер сообщения. Оно действует
на всю подписку: если хотя бы один активный фильтр его включает, каждая транзакция, которую получает
сессия, обогащается.Управляйте потоком без переподключения
В v1 вы задаёте свои фильтры один раз, в сообщении, которое открывает поток. Чтобы наблюдать за чем-то другим, вы разрываете соединение и открываете новое, теряя живой поток на время переподключения. v2 держит поток открытым и позволяет вам добавлять и удалять фильтры по ходу дела. Вы даёте каждому фильтру свой собственныйfilter_id, сервер подтверждает каждое добавление и удаление (и сообщает
причину, если отклоняет какой-то), и каждая транзакция перечисляет значения filter_id, с которыми
она совпала. Запускайте несколько фильтров на одном соединении, меняйте их на лету и всегда знайте,
какой фильтр породил данную транзакцию. Аккаунтные include / exclude / required ведут себя
точно так же, как в v1 — required работает по принципу любой-из (транзакция совпадает, если она
ссылается хотя бы на один перечисленный аккаунт), а не все-из.
Следуйте за цепочкой с помощью событий слотов
v2 добавляет второй, отдельный поток,SubscribeSlots, аналога которому у v1 нет. Вы получаете
событие, когда слот начинается (ALIVE), завершается (COMPLETE) или пропускается либо вытесняется
более поздними слотами без завершения (DEAD), вместе с лидером и родителем этого слота. Это дешёвый
способ отслеживать, где находится цепочка, вместо того чтобы выводить это из потока транзакций.
Знайте, когда вы что-то пропустили
Две вещи, которых v1 вам никогда не давал:- Каждое сообщение v2, как транзакции, так и события слотов, несёт номер
sequence, который возрастает на единицу. Увидели пропуск — и вы знаете, что потеряли сообщение. - Когда поток транзакций затихает, v2 отправляет
Heartbeatкаждые 60 секунд, помеченный часами сервера. Это поддерживает соединение живым через тайм-ауты простоя балансировщика нагрузки и отличает тихий поток от мёртвого.
Почему всё это складывается в более быстрый результат
- Круговой обход уходит с вашего критического пути. В v1 разрешение таблицы поиска — это полный RPC-запрос и ответ, намного медленнее самого потока. С включённым обогащением v2 разрешённые адреса версионной транзакции приходят прямо в сообщении, так что этот вызов никогда не встаёт между приходом транзакции и вашим действием.
- Меньше работы на транзакцию с вашей стороны. Поля обогащения приходят уже вычисленными, так что ваш клиент не выводит их заново на каждой транзакции.
- Никаких пропусков при переподключении. Изменение фильтров на лету означает, что вы никогда не разрываете поток, чтобы переподписаться.
- Потери и зависания видны немедленно благодаря номерам последовательности и heartbeat-сообщениям, а не выводятся постфактум.
Что вам следует использовать
Используйте v2 для новых интеграций. Именно здесь находятся обогащение, события слотов, живые фильтры и сигналы живости, и именно сюда попадает каждая новая возможность. v1 остаётся полностью поддерживаемым и пока не имеет установленной даты вывода из эксплуатации, так что существующий v1-клиент может продолжать работать как есть. Тем не менее мы призываем переходить: по мере того как всё больше трафика консолидируется на v2, это высвобождает мощности, которые мы сегодня выделяем на v1, для следующего поколения стриминга OrbitFlare. В любом случае миграция — это изменение в коде вашего клиента, а не в вашем соединении: те же эндпоинты, та же аутентификация, работающие бок о бок.Смотрите также
Обзор Jetstream v2
Модель потоковой передачи, подключение и лучшие практики.
Справочник протокола v2
Полная спецификация Protocol Buffer для v2, эндпоинты и генерация кода.
Jetstream (v1)
Обзор v1, примеры клиентов и руководство по фильтрации.