Matching Engine стоимостью более 50 000: начало
Соответствующий движок стоимостью более 50 000: версия MVP
Книга транзакционных ордеров
Книга заказовЭто основная и самая сложная структура данных во всем механизме сопоставления.Каждая пара транзакций должна вести журнал доверенных транзакций, а в реестре сохраняются все заказы, которые должны быть сопоставлены для указанной пары транзакций. В каждой книге есть две очереди: одна для ордеров на продажу и одна для ордеров на покупку. Обе очереди должны следоватьПриоритет цены, приоритет временипринцип сортировки.
Так называемый приоритет цены и приоритет времени означает, что заявки в очереди на продажу сортируются по цене от меньшей к высокой, а очередь заявок на покупку, наоборот, сортируется по цене от большей к меньшей; заявки с одинаковой ценой заказываются по времени заказа порядок в порядке.
Как показано на рисунке выше, каждый маленький квадрат представляет заказ, отмеченный значкомHпорядок наверху,NЭто ордер с той же ценой, что и H, но размещенный после H во время ордера.SЭто первый ордер по цене следующего транша. На рисунке хорошо видно, что по горизонтали заказы отсортированы по времени, а по вертикали – по цене.
При сопоставлении выньте его первымHЗаказ соответствует новому заказу. Если новый заказплатить, затем получитьОчередь ордеров на продажуПорядок H соответствует; если новый порядокЗаказы на продажу, затем получитьочередь на покупкуОрден Х. еслиHЕсли все заказы подобраны и выполнены, отметкаNзаказ становится новымHне замужем. Если все заказы в первой строке совпадают, тоSсингл станет новымHне замужем.
Книга транзакционных ордеров может поддерживать некоторые методы работы, включая инициализацию, добавление ордера на покупку и продажу, удаление ордера на покупку и продажу, получение основного ордера и т. д. Диаграмма классов книги транзакционных ордеров выглядит примерно так:
в,getHeadа такжеpopHeadРазница между методами заключается в следующем: get читает порядок заголовков, но не удаляет его, а pop удаляет порядок заголовков из очереди.
очередь заказов
Очередь ордеров на покупку и очередь ордеров на продажу могут быть разработаны для использования унифицированного типа очереди ордеров.Единственная разница между ними заключается в направлении сортировки цены, тогда очередь ордеров может использовать атрибут для представления направления сортировки. Все заказы в очереди могут храниться в двумерном массиве или двумерном связанном списке.Учитывая, что основными операциями являются вставка и удаление, использование связанного списка более эффективно, чем использование массива. Если вы хотите работать более эффективно, вам нужно использовать более сложную структуру данных, например комбинацию таблиц пропуска. Текущая версия проста и использует простой двумерный связанный список.
Если используется двумерный связанный список, каждый элемент в связанном списке хранит связанный список заказов, отсортированный по времени по горизонтали, и эти связанные списки заказов образуют связанный список, отсортированный по цене по вертикали.
Кроме того, вы также можете сохранить карту, использовать цену в качестве ключа и использовать список заказов с той же ценой, что и значение, что может ускорить запрос заказов с той же ценой.
Методы работы, поддерживаемые очередью заказов, также очень просты, включая инициализацию, добавление заказа, удаление заказа и получение главного заказа. Его диаграмма классов выглядит примерно так:
sortByУкажите направление сортировки по цене, **parentList** сохраняет весь двумерный связанный список, первое измерение сортируется по цене, второе измерение сортируется по времени,elementMapЭто пара ключ-значение, где Key — цена, а Value — двумерный список ордеров.
приказ
Форма заказа является самой базовой структурой данных в механизме сопоставления. Ее данные в основном передаются от вышестоящего сервиса. Диаграмма классов примерно выглядит следующим образом:
actionЧтобы объявить, какую операцию выполнять с заказом, нам нужно поддерживать только два типа операций:Оформить заказ (создать)а такжеОтмена.symbolУкажите торговую пару, к которой относится ордер,orderIdуникальный идентификатор заказа,sideуказать, что этокупитьвсе ещепродавать. **типУказывает тип транзакции, т.е.Лимит транзакции (лимит)илиРыночные транзакции** и т. д. Наша версия MVP поддерживает только лимитные транзакции. **сумма** — количество покупки,priceцена покупки,timestampэто время заказа.
**toJson()** иfromJson()Метод заключается в поддержке сериализации и десериализации передачи данных заказа.
Запись транзакции
Совпадающий порядок транзакции создаст соответствующую запись транзакции, и запись транзакции должна быть опубликована в MQ для последующего использования службы. Структура данных записи транзакции выглядит следующим образом:
makerОтносится к отложенному ордеру, который изначально находился в книге доверенных транзакций, иtakerЭто принять заказ, что означает съесть заказ производителя. **makerId** иtakerIdЭто идентификатор отложенного ордера и ордера тейкера.takerSideЭто направление покупки и продажи тейкера.Записи транзакций, которые мы видим в рыночном программном обеспечении, будут иметь разные цвета, которые определяются этим тейкером. **сумма** — количество транзакций,priceОтносится к цене транзакции, **timestamp ** — время транзакции.
Кэш Redis
Нам нужно использовать Redis для кэширования данных заказа и данных пары транзакций в процессе сопоставления.Есть две основные функции: одна для дедупликации запроса, а другая для восстановления данных после перезапуска программы.
Из-за прерывания сети или задержки или других ненормальных условий вышестоящая служба может повторно отправлять один и тот же запрос на соответствующий механизм.Поэтому программа должна быть дедуплицирована.Кэш данных может решить проблему дедупликации. Кроме того, поскольку мы используем сопоставление памяти, данные при сопоставлении сохраняются непосредственно в памяти программы. После выхода из программы все данные также исчезнут. После перезапуска нужно перезагрузить данные из других мест, с помощью Redis Cache можно кэшировать данные и загружать данные очень быстро.
При открытии движка торговых пар необходимо кешировать торговую пару, а при его закрытии он будет удален из кеша, чтобы обеспечить кеширование всех запущенных торговых пар.При перезапуске движок сопоставления этих торговых пар может быть перезапущен. Данные пары транзакций, которые необходимо кэшировать, включают два:symbolа такжеprice, то есть логотип и цена. Что касается цены, каждый раз, когда создается новая запись транзакции, цена также должна обновляться синхронно, поэтому обновление цены будет очень частым. Идентификатор в основном не нуждается в обновлении, поэтому их лучше кэшировать отдельно.
Символы всех торговых пар можно единообразно кэшировать в наборе. Мы можем установить значение ключа какmatching:symbols, используя Redissaddа такжеsremКоманда кэширует различные символы в значение ключа или удаляет их из ключа. Цена может быть сохранена в виде строки, а для цен разных торговых пар могут быть установлены разные ключи, значение ключа может быть установлено какmatching:price:{symbol}, {symbol} — значение символа конкретной торговой пары.
Каждый заказ также нуждается в кешировании и обновлении.Чтобы как можно быстрее прочитать и обновить данные заказа из кэша, лучше всего установить отдельный ключ для каждого заказа.Значение ключа можно установить равнымmatching:order:{symbol}:{orderId}:{action}, а значение value рекомендуется задавать хеш-типом, потому что хеш-тип особенно подходит для хранения структурированных объектов.
И пара транзакций, и данные ордера кэшируются, что может решить проблему дедупликации и перезапустить механизм сопоставления каждой пары транзакций после перезапуска программы.Однако остается проблема, как восстановить книгу ордеров транзакций в соответствующий двигатель? Этот вопрос предоставляется каждому для размышления в первую очередь, и я объясню свой план в следующих главах.
резюме
На самом деле, в механизме сопоставления задействовано не так много структур данных, а наиболее сложным является только реестр доверенности транзакций, и его структура также напрямую связана со скоростью сопоставления. В дизайне кэша Redis также есть некоторые знания, и если он плохо спроектирован, это также повлияет на общую производительность сопоставления. В этом разделе завершается проектирование структуры данных, а в следующем разделе мы начинаем погружаться в реализацию кода.
Наконец, пожалуйста, найдите время, чтобы изучить оставшиеся вопросы: Как восстановить книгу заказов транзакций в механизме сопоставления?
Отсканируйте QR-код ниже, чтобы подписаться на официальный аккаунт.