Почему индексатор TON не успевает за ростом нагрузки
Индексатор TON начинает отставать не на пике, а раньше — когда поток событий из сети устойчиво быстрее, чем подтверждённая запись в хранилище. Сначала разрыв измеряется единицами блоков и не виден в ответах API, потом растёт лавинообразно: очередь становится длиннее окна, которое воркеры успевают пройти за один проход. Типовых причин четыре, и все они про устройство цикла обработки, а не про мощность железа.
Переобработка блоков: после реорганизации ветки воркер часто переигрывает весь диапазон, а не только затронутые транзакции. Каждый пропущенный блок в очереди оплачивается двойной работой, а промежуточные состояния в хранилище потом приходится сверять отдельно. Конкуренция за узлы добавляет своё: при ограниченном числе точек доступа часть запросов отваливается по лимитам, разные воркеры читают состояние на разных моментах, и в API всплывает расхождение балансов.
Отдельная история — схема ключей. Ключ вида «адрес плюс дата» размазывает записи по горячим разделам, пакетная запись не собирается, писатель упирается в дисковые операции — и отставание растёт уже на выходе. Ключ по диапазону шарда с накоплением пачки даёт ровный поток и предсказуемую задержку между событием в сети и его появлением в хранилище.
Пропущенные блоки опасны не сами по себе, а тем, что их догон конкурирует с текущим потоком за те же узлы и диск. Поэтому отставание считают отдельной метрикой по каждому шарду, а не средней по сервису, и решения принимают по ней. Разбираем, как это закрывается: где ставить границы окна переобработки, как развести чтение и запись между узлами и какой формат ключа держит запись ровной.
Что даёт управляемая индексация: измеримый эффект
Управляемый индексатор TON держит отставание от головы сети в пределах одного-двух подтверждённых блоков — вместо минут ожидания после каждой транзакции. Реорганизации обрабатываются переигровкой затронутого диапазона высот, а не полной переиндексацией всей истории.
Полнота истории держится на журнале обработанных мастерчейн-блоков: для любой высоты восстанавливается состояние аккаунта, его события и переводы. Корректность проверяется сверкой контрольных сумм состояния по случайным высотам — расхождения видны до того, как их заметит пользователь.
Устойчивость к повторной обработке даёт идемпотентная запись: ключ из высоты блока и хеша транзакции не позволяет дублировать данные. Воркер, упавший на середине диапазона, продолжает с последней контрольной точки и не теряет ни одного события.
Нагрузка на узлы снижается подпиской на новые блоки вместо постоянного опроса, пакетными запросами и кэшем горячих аккаунтов — обращений к узлу становится меньше на порядок. Освободившийся запас уходит на глубокие запросы к истории: выдача по адресу или по токену отвечает за доли секунды даже на длинном диапазоне высот.
Режимы индексации: сравнение подходов и ограничений
Выбор режима определяет не только скорость появления данных в API, но и то, как индексатор TON переживает реорганизации и пропуски. На входе два параметра: допустимая задержка между финализацией блока и его видимостью в ответе, и глубина хранения — сколько истории нужно поднимать по запросу.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Потоковая индексация | Витрины, кошельки, балансы и статусы транзакций: ответ нужен почти сразу после финализации | Нужен буфер под реорг и идемпотентная запись по ключу блока; сбой парсера останавливает весь поток, а историю задним числом не пересчитать |
| Пакетные пересчёты | Аналитика, сверка балансов, миграция схемы хранения, восстановление после сбоя | Данные появляются с задержкой от десятков минут; повторный проход по архиву узла дорог по нагрузке на диск и на хранилище |
| Гибридная схема | Публичный API индексатора TON, где важны и свежие данные, и глубокая выборка | Сложнее в эксплуатации: два контура, отдельные чекпоинты и согласование границы между горячим и холодным слоями |
Глубина хранения — отдельная ось и её не стоит путать с режимом. Свежие блоки держим в быстром хранилище, историю — в сжатом, с заранее описанной политикой удаления: сколько последних блоков гарантируем для отката, что уходит в архив, что пересчитывается из него по требованию. Гибрид обычно и становится рабочим вариантом: поток даёт низкую задержку, пакетный проход закрывает дыры и наполняет исторические срезы.
На практике режим подбирается под профиль запросов, а не наоборот: сначала смотрим, какие выборки преобладают, потом фиксируем задержку и глубину.
Этапы внедрения индексатора TON
Порядок работ один и для нового индексатора TON, и для замены самописного скрипта, который перестал успевать за потоком блоков. Сначала фиксируем, какие запросы к данным нужны продукту, и только затем выбираем схему хранения: если начать с кода, переписывать приходится на середине. Ниже — последовательность с точками приёмки на каждом этапе.
- Аудит схемы данных. Разбираем таблицы, связи и тяжёлые запросы, отмечаем нехватку составных индексов и дубли. На выходе — карта источников и план переноса.
- Проектирование модели хранения. Решаем, что держим нормализованно, а что — в денормализованных проекциях под частые выборки: историю адреса, балансы, события контрактов.
- Настройка очередей. Поток блоков делим на приём, разбор и запись; очередь гасит пики, а после сбоя обработка идёт с последней подтверждённой позиции.
- Проверка консистентности. Сверяем индекс с данными сети по балансам, числу транзакций и повторной обработке; расхождения сводим к нулю на тестовом диапазоне.
- Нагрузочный прогон и переключение. Смотрим отставание индексатора на исторических данных и в реальном времени, переводим трафик поэтапно, с возвратом к прежнему контуру.
- Передача регламентов. Отдаём описание схемы и запросов, инструкции по перезапуску и восстановлению, метрики с порогами. Дальше эксплуатация идёт силами вашей команды.
Комплект поставки: схемы, регламенты, инструменты
После запуска у команды заказчика остаётся не только работающий сервис, но и комплект документов, по которым его можно эксплуатировать и развивать без нас. Передаём описание схемы данных, регламенты и инструменты наблюдения — так, чтобы дежурный инженер понимал причину сбоя, а новый разработчик добавил метод API без разбора чужого кода.
- Схема данных — какие таблицы хранят блоки, транзакции и события, по какому ключу идёт разбиение на партиции и какие индексы закрывают частые запросы по адресу и временному периоду.
- Спецификация API индексатора TON — перечень методов, форматы ответов, курсорная пагинация, лимиты и коды ошибок: по ней интеграцию пишут без уточняющих вопросов.
- Доступы и роли — сервисный доступ только на чтение, отдельные ключи для аналитики, административные операции, порядок ротации и изоляция стенда от промышленного контура.
- Регламент перезапуска — в какой последовательности поднимаются компоненты, как сервис добирает пропущенные блоки и от какой точки возобновляет обработку, чтобы события не задвоились.
- Мониторинг очередей — метрики глубины очередей, отставания индекса от цепочки и доли отброшенных сообщений, пороги алертов и первые шаги дежурного при срабатывании.
- Снимки и восстановление — как снимается состояние хранилища, где оно хранится и сколько занимает возврат к рабочему режиму.
- Разбор типовых сбоев — рассинхрон, дубли событий, отставший узел: по каким признакам распознаются и что делать по шагам.
- Передача знаний — запись разбора архитектуры и ответы на вопросы команды, чтобы эксплуатация не зависела от одного человека.
Кейс: как выросла полнота данных после перезапуска
Что было до перезапуска
Индексатор собирали под быстрый запуск: блоки читались в один поток, всё писалось в одну таблицу без разбиения по шардам. На пике отставание от сети доходило до нескольких часов, а при рассинхронизации процесс молча пропускал диапазон блоков — дыры находили по жалобам сервисов, которые строились на этих данных.
Полнота истории держалась около 88%: часть внутренних переводов и событий контрактов в индекс не попадала. В TON это критично — пропущенный диапазон рвёт цепочку состояний у зависимых адресов, и реальный баланс уже не отличить от накопленной ошибки.
Что изменили и что стало
Загрузку переписали на параллельную обработку шардов с контрольными точками, переиндексацию сделали управляемой: глубина задаётся параметром — от последних часов до всей истории сети. Восстановление после сбоя теперь автоматическое, с последней подтверждённой точки, без ручного разбора.
- Отставание от сети на пике — минуты вместо часов.
- Полнота истории — 100% по проверенным диапазонам, контрольные суммы сходятся по каждому шарду.
- Восстановление после сбоя — около 20 минут автоматического доигрывания вместо часов ручной работы.
- Глубина переиндексации — вся история, а не окно в последние сутки.
Сверяли не на глаз: прогнали индекс против полного узла на нескольких диапазонах, расхождений нет. После перезапуска команды перестали держать собственные выгрузки — данные из индекса совпадают с сетью и отдаются сразу.
Что делать, если индексатор уже развёрнут и отстаёт
Индексатор TON в эксплуатации отстаёт по двум причинам: изменилась схема учёта — добавились внутренние переводы, изменился состав полей — либо выросли объёмы, и цикл обработки блока перестал укладываться в интервал. Останавливать сервис нельзя: балансы и история операций нужны постоянно, а прогон с нуля занимает часы.
Рабочий приём — постепенная миграция через двойную запись. Обработчик пишет и в старую, и в новую схему в одной транзакции, поэтому состояния не расходятся. Читающий слой переключается не целиком, а по группам запросов: откат сводится к снятию флага, а не к восстановлению из резервной копии.
Историю переносим в фоне. Фиксируем высоту блока, с которой началась двойная запись, — это точка расхождения. Всё, что было раньше, заливаем пакетами в новую схему параллельными обработчиками с ограничением нагрузки на узел, чтобы живой поток не отставал сильнее. Догоняем до нуля расхождения.
Смена схемы безопаснее, чем кажется: новая таблица живёт рядом со старой, конфликтов по блокировкам нет. Обязательна сверка — контрольная выборка адресов и операций прогоняется через обе схемы, ответы сравниваются автоматически, и только после совпадения чтение уходит на новую.
Если отставание уже накопилось, его снимают пересборкой горячего слоя из архива блоков, не трогая накопленные данные. Начинать с нуля не стоит: теряются история балансов и сделок, а восстановление занимает сутки. Старый слой оставляем читаемым, пока новый не докажет совпадение на сверке.
Технические сомнения перед стартом работ
Индексатор — это состояние, которое обязано совпадать с цепочкой при любом сбое: пропущенный блок, разрыв соединения, реорганизация последних блоков. Ниже — ответы на инженерные вопросы, которые чаще всего поднимают на этапе оценки: целостность, повторная обработка, доступы и границы ответственности после передачи.
Как подтверждается целостность данных по каждому блоку?
Каждый обработанный блок фиксируется с его хешем, номером, родительским хешем и меткой времени записи. Сверка идёт от последней подтверждённой отметки: если родительский хеш не совпадает с уже сохранённым, партия блоков откатывается до общей точки и обрабатывается заново. Итоговая проверка — контрольная сумма состояния за окно блоков, она сверяется независимо от основного цикла разбора.
Что будет, если индексатор остановился на несколько часов?
Разбор идёт по курсору, а не по времени, поэтому после запуска обработка продолжается с последней подтверждённой отметки. Операция записи идемпотентна: повторная обработка того же блока не создаёт дублей в хранилище. Отставание выбирается пакетами до выхода на актуальную высоту, дальше включается обычный режим.
Как устроены права доступа к развёрнутому контуру?
Доступы выдаются ролями: чтение через интерфейс данных, служебные операции по разбору и миграциям — отдельно. Ключи и учётные данные передаются вашему ответственному лицу, у нас не остаётся постоянного доступа. Отзыв доступа с нашей стороны фиксируется письменно и подтверждается попыткой подключения с обеих сторон.
Как делится ответственность после передачи?
Передаём конфигурации разбора, схему хранилища, политику повторной обработки, инструкции по восстановлению и порядок действий при расхождении состояний. Ваши инженеры восстанавливают контур по этим материалам без нашей помощи. Гарантийное сопровождение покрывает ошибки логики разбора — они воспроизводятся и устраняются; изменения вашей инфраструктуры и правила доступа к узлам остаются на вашей стороне.
Обсудим вашу задачу и вернёмся с планом
Чтобы оценка проекта опиралась на факты, а не на предположения, на старте нам важно понять границы: нужна ли история с первых блоков или достаточно окна за последние периоды, какие сущности обязаны быть в ответе, какую задержку между появлением блока в сети и его видимостью в API вы считаете допустимой. Ещё два параметра — откуда идёт поток данных (свои узлы или внешние источники) и какой запас по нагрузке закладывать, чтобы индексатор не отставал от головы цепи при пиковых всплесках.
По итогам разговора вы получите:
- схему парсинга: обход шардов, порядок обработки мастерчейна и рабочих цепочек, поведение при реорганизациях и повторной выдаче блоков;
- модель хранения с описанием индексов под конкретные запросы — чтобы выборки по адресу, транзакции и истории держали нужную скорость на ваших объёмах;
- контракт API с примерами ответов и полями, включая пагинацию, фильтры и признаки финальности;
- план работ по этапам с точками приёмки на каждом: сырой поток, наполнение хранилища, свой API, нагрузочные проверки;
- состав команды с ролями — кто отвечает за парсинг, кто за слой запросов, кто за сопровождение;
- план передачи в эксплуатацию: дашборды отставания от головы цепи, регламент переиндексации после сбоев, порядок обновления при изменении формата блоков;
- перечень рисков и допущений, влияющих на сроки и объём.
Опишите задачу в свободной форме — объёмы, источники, требования к ответам. Мы вернёмся с оценкой, планом работ и ролями в команде.
