Система Сопоставления Заявок на Криптобирже

В 2026-ом году требования к торговым системам вышли на новый уровень: низкая задержка (Low-Latency), детерминированное выполнение (Deterministic Execution), масштабирование до 1-го миллиона транзакций в секунду (1M+ TPS) и полное соответствие регуляторным требованиям (Regulatory Compliance). Но за этими терминами стоит не только код.



Фундаментом выступает сложная инженерная экосистема, где важна каждая микросекунда и каждое архитектурное решение. Это двигатель сопоставления (matching engine).

Что такое система сопоставления заявок? «Мозг» современных бирж

Двигатель сопоставления (Matching engine) — это ядро любой криптобиржи, отвечающее за сопоставление заявок (orders) между покупателями и продавцами. Именно здесь формируется ликвидность (Liquidity), определяется спред цены покупки и продажи (Bid-Ask Spread), а также происходит реальное исполнение сделок.

За пределами определения: почему это самая важная часть вашей инфраструктуры

В торговой практике двигатель сопоставления является пространством, где сходятся:

• задержка (микро- и наносекунды определяют уровень прибыли);



• детерминированное выполнение (повторяемость результатов);



• целостность рынка Market Integrity (защита от манипуляций);



• контроль проскальзывания (разница между ожидаемой и реальной ценой).

В сегменте высокочастотной торговли (high-frequency trading) разница даже в несколько микросекунд может означать потерю прибыли. Именно поэтому инфраструктура вокруг двигателя сопоставления (сетевой стек, управление памятью, локальность кэша) часто важнее самого алгоритма.



По данным Nasdaq TotalView ITCH (2025), до 90% всей ликвидности формируется алгоритмическими ордерами, а среднее время обработки заявки в топовых биржах США — менее 50 мкс.



По данным современных криптобирж, механизм сопоставления вне сети (off-chain matching) позволяет достигать задержки в миллисекунды и более 200K TPS. Высокопроизводительные криптобиржи уже демонстрируют показатель в 100K+ TPS и менее 10 миллисекунд задержки.

Централизованное и децентрализованное сопоставление: скорость против прозрачности

Сегодня большинство институциональных трейдеров в США и Европе отдают предпочтение движкам централизованных бирж, что обусловлено низкой задержкой (Low-Latency) и контролем исполнения.



Ниже представлена таблица их сравнения.







При этом трилемма обмена остается актуальной и требует поиска эффективного компромисса — что напрямую влияет на стоимость создания DEX.









Увы, невозможно одновременно максимизировать скорость, децентрализацию и капитальную эффективность:

1. Если акцент падает на высокочастотную торговлю и арбитраж с минимальной задержкой, тогда имеет место централизованная модель сопоставления.



2. Если в приоритете прозрачность и самостоятельное хранение средств, тогда выигрывает модель децентрализованного сопоставления.

Анатомия торговой сделки: что происходит «за кулисами»?

Когда трейдер нажимает кнопку Buy (купить) или Sell (продать), кажется, что торговая сделка выполняется мгновенно. Но за этим действием стоит сложная последовательность компонентов. Они должны работать синхронно, обеспечивать минимальную задержку и гарантировать детерминированное исполнение.



Этот механизм базируется на трех элементах: шлюз ордеров (Order Gateway), секвенсор (Sequencer), книга ордеров (Order Book).



Именно их архитектура определяет, сможет ли система масштабироваться до сотен тысяч или даже 1M+ TPS без потери стабильности — тема, которую мы подробно рассматриваем в нашем руководстве по архитектуре криптобирж.

Шлюз обработки заказов: проверка и нормализация входящего трафика

Шлюз ордеров (Order Gateway) — это первая точка входа для всех заявок в систему.



Здесь «сырой» трафик превращается в стандартизированные и безопасные команды для двигателя сопоставления.



Основные функции шлюза:

• валидация типов ордеров (Limit Order, Market Order);



• проверка баланса пользователя;



• контроль ценовых диапазонов (защита от «fat-finger» ошибок);



• ограничение скорости (Rate limiting) и анти-DDoS механизмы;



• нормализация данных во внутренний формат.

В высокопроизводительных системах шлюз ордеров работает через:

• TCP/UDP Multicast для доставки маркет-данных;



• FIX/FAST Protocol для институциональных клиентов;



• двоичное кодирование (SBE/Protobuf) для минимизации задержки.

Любая задержка или ошибка на этом этапе масштабируется дальше по системе. Если шлюз не оптимизирован, вы теряете ликвидность еще до того, как ордер попадет в книгу ордеров.

Секвенсор: обеспечение детерминированного выполнения порядков

Секвенсор (Sequencer) как компонент архитектуры часто недооценивается. Но именно он обеспечивает порядок в хаосе тысяч параллельных заявок.



Его ключевые задачи:

• присваивать идентификаторы последовательностей (Sequence IDs) каждому ордеру;



• обеспечивать строгий порядок выполнения;



• гарантировать детерминированное исполнение (Deterministic Execution).

Без секвенсора возникает хаотичное поведение, появляются проблемы с аудитом, а также повышаются риски для рыночной целостности. Как следствие, невозможно достичь эффективной проверки на нормативном уровне.

Книга ордеров: как структуры данных влияют на задержку

Книга ордеров (Order Book) — это сердце двигателя соответствия, где хранятся все активные заявки: Bid (покупка) и Ask (продажа).



Именно в книге формируется ценовая разница (Bid-Ask Spread) и проходит соответствие.



Сравнение структуры данных приведено в таблице ниже:











Почему локализация кэша важнее Big-O:

• в теории дерево может выглядеть эффективно (O(log n)), но на практике кэш теряется и это ведет к задержке на десятки наносекунд. Как следствие, погоня за цифрами ведет к непредсказуемой задержке;



• в двигателе соответствия должна использоваться непрерывная память в виде массивов для оптимизации под CPU cache и минимизации распределений.

Такой подход позволяет избежать блокировки (blocking I/O), сохранить минимальную задержку и масштабироваться без деградации производительности.

Популярные алгоритмы сопоставления: выбор правильной логики для вашего рынка

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

• как распределяется ликвидность (Liquidity) — и какие провайдеры ликвидности найдут вашу платформу привлекательной;



• какой уровень проскальзывания (Slippage) получают трейдеры;



• насколько привлекателен ваш рынок для маркет-мейкеров.

Одна и та же ордерная книга может вести себя совершенно по-разному в зависимости от выбранной логики.

Приоритеты FIFO, пропорционального распределения и соотношения цены и времени брокера

Как выбрать правильный алгоритм для работы биржи: здесь все зависит не от технологий, а от вашей бизнес-модели.

1. Если ваша цель — спотовая биржа с розничными трейдерами и простым UX, то оптимальным решением будет FIFO.



2. Если вы строите деривативную платформу или HFT-экосистему с глубокой ликвидностью, выгодно выбирать Pro-Rata — смотрите, как мы реализовали это в нашем кейсе по бинарным опционам и фьючерсной торговле.



3. Если вы ориентируетесь на институциональных игроков, брокерские модели и кастомные правила исполнения, тогда имеет место Price-Broker-Time.

Разработка решений с низкой задержкой: технические аспекты от Merehead

В высокочастотных торговых системах задержка (latency) — это не просто метрика. Это фактор прямого влияния на прибыль, ликвидность и конкурентоспособность.



Далее мы объясняем наш практический опыт построения двигателя сопоставления, который стабильно работает в режиме низкой задержки (Low-Latency) и масштабируется до сотен тысяч TPS без деградации.

Ловушка для сбора мусора

Одна из самых распространенных ошибок — это использование языков Garbage Collection (GC) для ядра движка.



На первый взгляд все выглядит просто и эффективно:

• Java/Node.js обеспечивает быструю разработку;



• большая экосистема;



• много готовых решений;

Но в реальной практике языки GC создают непредсказуемые паузы, которые критичны для высокочастотного трейдинга (HFT). Даже короткие задержки в 1-10 мс ломают детерминированное исполнение и создают всплески задержек (P99, P999) — что критично для алгоритмических торговых ботов.







В чем преимущества использования Rust:

• отсутствие GC;



• контроль памяти без незапланированных расходов;



• полностью предсказуемое исполнение;



• абстракции с нулевой стоимостью.

Однопоточные циклы событий против многопоточных циклов событий

Ключевая проблема заключается в конфликте блокировок, переключении контекста и непредсказуемой задержке.



В наших разработках мы используем однопоточный цикл событий (Single-threaded Event Loop). Он характеризуется такими преимуществами:

• один поток на один двигатель сопоставления;



• конвейер, управляемый событиями;



• очереди без блокировок для передачи данных.

Ключевая особенность однопоточного цикла событий в том, что он похож на LMAX Disruptor и Node.js event loop, но реализован на уровне системного программирования (Rust/C++). При этом имеет такие особенности:

• без мьютексов;



• без переключения контекста;



• стабильная задержка.

Таким образом, масштабирование достигается не через потоки, а через разделение и горизонтальное масштабирование.

Бинарные протоколы против JSON

И сразу можно привести сравнительную таблицу ключевых параметров:







В нашей практике разработки проектов мы используем протоколы SBE (Simple Binary Encoding) и ProtoBuf.



Среди ключевых преимуществ SBE:

• синтаксический анализ без копирования;



• минимальная сериализация;



• оптимизирован под локальность кэша.

Бинарные протоколы полезны и важны тем, что позволяют:

• снизить задержку на 10-30%;



• снизить нагрузку на CPU;



• стабилизировать пропускную способность.

Надежность и аварийное восстановление: уроки из практики

Далее мы подробно разберем наш практический опыт построения системы, которая выдерживает сбои без потери ликвидности и доверия пользователей.

Дилемма моментальных снимков

Мы реализовали систему снимков состояния системы (Snapshots). Она подразумевает фиксацию каждые 50-100 мс и сохранение состояния книги ордеров. Таким образом, достигается эффективное восстановление после сбоя < 100 мс.



Основная проблема восстановления системы после катастрофы заключается в:

• полный лог операций ведет к медленному восстановлению;



• «голая» система снимков формирует риск потери данных.

Для решения дилеммы важно достичь баланса.



Наш подход таков: система снимков Snapshot + журнал всех событий. То есть мы комбинируем снимки состояния, отслеживаем полное состояние книги ордеров, фиксируем все активные лимитные ордера и позиции пользователей. Одновременно с этим ведется журнал событий (Incremental logs): что происходит после снимков состояния, а также идет запись через Memory-mapped files (mmap).



Как это работает на практике:

• Snapshot каждые 50-100 мс;



• логирование каждого события (order add/cancel/match).

Если происходит сбой, то последовательность восстановления такая: сначала загружается последний snapshot, затем проигрывается лог.



В результате время восстановления < 100 мс, гарантируется нулевая потеря данных и происходит полное восстановление книги ордеров.



Сравнение подходов можно увидеть в таблице ниже:

Детерминизм — король

В финансовых системах недостаточно просто восстановить сбой. Здесь важно гарантировать:

• исполнение ордеров в том же порядке, что и до сбоя;



• идентичность и сохранность спреда (Bid-Ask Spread);



• одинаковые результаты после аудита.

Для реализации задействуются следующие инструменты:

• идентификаторы последовательностей (Sequence IDs);



• постоянные журналы (Persistent logs);



• хранилище (mmap storage).

Благодаря идентификаторам последовательностей каждый ордер получает уникальный ID и позицию в глобальной очереди. Это формирует базу детерминированного исполнения.



Постоянные журналы позволяют записывать все события в строгом порядке и через лог «только для добавления». Никаких параллельных записей.



Однопоточный цикл событий дает такие преимущества:

• отсутствие гонки;



• полностью предполагаемый конвейер;



• 100% воспроизводимость после рестарта;



• соответствие требованиям регуляторного соответствия;



• возможность полного аудита.