Jak działa architektura matching engine na giełdzie

Wprowadzenie do architektury matching engine

Matching engine łączy kupujących i sprzedających, przetwarzając zlecenia w czasie rzeczywistym. Odbiera, sprawdza, szereguje i dopasowuje każde zlecenie.

Termin matching engine architecture stock exchange obejmuje cały ten projekt. Zawiera gatewaye, kontrole ryzyka, order booki, zdarzenia transakcyjne i narzędzia odtwarzania.

Szybkość ma znaczenie, ale sama szybkość nie wystarczy, aby stworzyć solidny system. Engine musi zachować kolejność zleceń podczas wzmożonego ruchu na rynku.

Musi także odzyskiwać działanie bez zmieniania wcześniejszych wyników. Ta potrzeba wpływa na każdą część systemu.

• Gatewaye odbierają zlecenia klientów
• Kontrole ryzyka blokują niebezpieczne zlecenia
• Order booki przechowują otwarte zlecenia
• Rdzeń dopasowywania zawiera transakcje
• Systemy danych rynkowych publikują aktualizacje
• Magazyn audytowy zapisuje kluczowe zdarzenia

Każda część potrzebuje jasno określonej roli. Taki podział ułatwia testowanie i kontrolę awarii.

Kluczowe komponenty matching engine

Matching engine składa się z kilku części, które tworzą jedną zsynchronizowaną ścieżkę. Każda z nich obsługuje wąskie zadanie.

Warstwa gateway zarządza sesjami sieciowymi i formatami komunikatów. Może obsługiwać FIX — powszechny standard komunikatów transakcyjnych.

Może odrzucać nieprawidłowe komunikaty, zanim dotrą do rdzenia. Dzięki temu błędne dane wejściowe nie trafiają do głównej pętli.

Warstwa ryzyka sprawdza przedziały cenowe, limity wielkości, środki na rachunku i status handlu. Kontrole te muszą działać szybko.

Order book przechowuje oczekujące zlecenia kupna i sprzedaży w uporządkowanej formie. Zlecenia kupna są szeregowane od najwyższej ceny w dół.

Zlecenia sprzedaży są szeregowane od najniższej ceny w górę. Większość rynków ciągłych stosuje priorytet ceny i czasu.

Najlepsza cena jest na pierwszym miejscu. Zlecenia z tą samą ceną są następnie ustawiane według zaakceptowanego czasu.

Komponent	Główne zadanie	Kluczowa potrzeba projektowa
Gateway	Przyjmowanie komunikatów klientów	Stabilne sesje i szybkie parsowanie
Warstwa ryzyka	Blokowanie niebezpiecznych zleceń	Przewidywalne kontrole
Order book	Szeregowanie otwartych zleceń	Szybkie aktualizacje i odczyty
Rdzeń dopasowywania	Zawieranie transakcji	Stała i sprawiedliwa kolejność
Dane rynkowe	Udostępnianie aktualizacji order booka i transakcji	Rozsyłanie danych z niskim opóźnieniem

Giełda potrzebuje także warstwy danych rynkowych. Udostępnia ona zmiany w order booku, transakcje i zdarzenia dotyczące statusu.

Oddzielny magazyn audytowy przechowuje pełny rejestr. Typy zleceń dodają kolejne reguły do tej ścieżki.

Zlecenie z limitem określa cenę. Zlecenie rynkowe szuka najlepszych dostępnych cen.

Zlecenia anulowania i zastąpienia również muszą zachowywać czytelną kolejność. Niewielkie luki w regułach mogą prowadzić do niesprawiedliwych wyników.

Jak działa przepływ przetwarzania zleceń

Przepływ przetwarzania zlecenia rozpoczyna się, gdy trader wysyła komunikat. Gateway sprawdza jego format i sesję.

Następnie nadaje mu numer sekwencyjny. Warstwa ryzyka sprawdza zlecenie pod kątem zasad rachunku i rynku.

Engine odrzuca nieprawidłowe zlecenia, podając jasny powód. Zaakceptowane zlecenia trafiają do rdzenia w ustalonej kolejności.

Rdzeń porównuje nowe zlecenie z przeciwną stroną order booka. Zlecenie kupna może zostać dopasowane do sprzedaży po dozwolonej cenie.

Engine najpierw realizuje mniejszą ilość. Niezrealizowana część jest obsługiwana zgodnie z typem zlecenia.

1. Odbiór komunikatu przez gateway transakcyjny
2. Sprawdzenie formatu, sesji, limitów i stanu rachunku
3. Przypisanie stałej pozycji w sekwencji
4. Porównanie zlecenia z przeciwną stroną order booka
5. Utworzenie jednej lub większej liczby realizacji
6. Aktualizacja order booka i publikacja zdarzeń
7. Zapis pełnego rejestru zdarzeń

Każda zmiana stanu powinna generować zdarzenie. Zdarzenia te wspierają dane rynkowe, rozliczenia, raporty i późniejszą analizę.

Narzędzie replay może odbudować order book na podstawie tych rejestrów. Pomaga to zespołom testować awarie i wyjaśniać wcześniejsze transakcje.

The SEC's overview of order handling wyjaśnia, dlaczego zasady routingu i realizacji mają znaczenie.

Projektowanie z myślą o niskich opóźnieniach i uczciwym handlu

Opóźnienie oznacza czas między nadejściem komunikatu a działaniem engine. Wiodące platformy dążą do przetwarzania na poziomie mikrosekund.

Niskie opóźnienie wymaga krótkiej i stabilnej ścieżki kodu. Zespoły często przechowują rdzeń w pamięci.

W miarę możliwości unikają blokad. Wstępnie alokują również kluczowe obiekty.

Wybór struktur danych wpływa na szybkość. Drzewo utrzymuje uporządkowane ceny przy stałym czasie aktualizacji.

Tablice mogą dobrze działać, gdy poziomy cen mieszczą się w znanym zakresie. Właściwy wybór zależy od projektu rynku.

Firmy zajmujące się handlem wysokiej częstotliwości szukają niewielkich zysków na całej ścieżce sieciowej. Giełdy mogą wykorzystywać sprzęt FPGA do obsługi feedów.

Kernel bypass pozwala, aby dane sieciowe omijały część systemu operacyjnego. Może to ograniczyć opóźnienia przy dużym ruchu.

Metody te mogą ograniczyć opóźnienia, ale zwiększają koszty i ryzyko projektowe. Zespoły muszą testować je przy rzeczywistym obciążeniu.

• Pomiar opóźnień gatewaya, warstwy ryzyka, rdzenia i feeda
• Śledzenie opóźnień przy dużym i małym natężeniu ruchu
• Testowanie priorytetu ceny i czasu przy nagłych skokach obciążenia
• Rejestrowanie odrzuconych zleceń i ich powodów
• Porównywanie wyników replay z wynikami na żywo

Uczciwość zależy także od projektu zegara. Każdy komunikat musi mieć jasno określone miejsce w strumieniu zdarzeń.

Operatorzy powinni publikować zasady dotyczące remisów, przerw, odrzuceń i żądań anulowania. Jasne reguły pomagają firmom ufać platformie.

Strategie skalowania silników matching engine

Jeden silnik może dobrze obsługiwać mały rynek. Większe platformy często dzielą pracę według instrumentu lub grupy rynków.

Dedykowany silnik może obsługiwać akcje, opcje lub kontrakty futures. Dzięki temu duży ruch na jednym rynku nie spowalnia pozostałych.

Połączenia z bramami mogą być skalowane horyzontalnie na wielu serwerach. Rdzeń nadal potrzebuje jednego, jasno określonego strumienia zleceń dla każdego order booka.

Dane rynkowe można następnie rozsyłać za pośrednictwem oddzielnych feedów. Nie powinny one blokować dopasowywania zleceń.

Skalowanie rdzenia jest trudniejsze niż skalowanie bram. Dwa rdzenie nie mogą bezpiecznie zapisywać danych do jednego order booka bez ścisłej kontroli.

Metoda skalowania	Najlepsze zastosowanie	Główne ryzyko
Podział według instrumentu	Oddzielanie aktywnych rynków	Koordynacja między rynkami
Więcej bram	Obsługa większej liczby sesji klientów	Nierównomierny ruch
Oddzielne feedy	Obsługa wielu odbiorców danych	Nieaktualne aktualizacje
Repliki do odtwarzania	Wsparcie odzyskiwania danych i testów	Rozbieżność stanu

Każdy shard potrzebuje jasno określonego właściciela. Zespoły powinny zdefiniować, gdzie trafiają zlecenia i gdzie przechowywane są rekordy.

Testy odzyskiwania danych są równie ważne jak testy obciążeniowe. Dobrze zaprojektowany system może uruchomić się ponownie bez utraty zaakceptowanych zdarzeń.

Obowiązki regulacyjne i mechanizmy audytu

Zasady giełdy wymagają czegoś więcej niż szybkiego matching engine. Wymagają również przejrzystych rekordów każdego zlecenia i każdej transakcji.

Ślad audytowy powinien rejestrować czas nadejścia, pozycję w sekwencji, zmiany, odrzucenia, realizacje oraz zdarzenia wyjściowe.

Rekordy powinny wskazywać, kto wysłał dane zlecenie. Powinny również pokazywać, które zasady pozwoliły je zrealizować lub zablokowały jego przetwarzanie.

Obsługa zleceń musi być zgodna z opublikowanymi zasadami rynku. Obejmują one przedziały cenowe, wstrzymania obrotu, typy zleceń i zmiany transakcji.

The Zbiór zasad ESMA MiFID II określa kluczowe wymogi dla platform obrotu w Unii Europejskiej.

Mechanizmy kontrolne powinny zapobiegać niejawnej edycji wcześniejszych rekordów. Magazyny typu write-once i podpisane łańcuchy zdarzeń mogą wspierać ten cel.

Ograniczenia dostępu również mają znaczenie. Tylko upoważnieni pracownicy powinni zmieniać ustawienia ryzyka lub uruchamiać ponownie rynek.

• Zachowuj pełny ślad zdarzeń dla każdego zlecenia
• Chroń rekordy przed niejawnymi zmianami
• Testuj awaryjne zatrzymania i wstrzymania obrotu
• Weryfikuj zasady ryzyka po każdej zmianie systemu
• Porównuj rekordy transakcji z rekordami rozliczeniowymi

Zespoły powinny przechowywać zarówno dane bieżące, jak i dane do odtwarzania. Dzięki temu mogą wyjaśniać spory na podstawie tego samego stanu, który obowiązywał w danym momencie.

Dobre mechanizmy kontrolne ograniczają ryzyko prawne i przyspieszają analizę incydentów. Sprawiają również, że aktualizacje systemu są bezpieczniejsze.

Najważniejsze wnioski i przyszłe trendy

Matching engine łączy szybkość, zasady obsługi zleceń, dane rynkowe i kontrolę audytową. Żaden pojedynczy element nie jest w stanie samodzielnie zapewnić kompletnej architektury.

Order book musi pozostać uporządkowany i sprawiedliwy. Przepływ przetwarzania musi zachować stałą kolejność w warunkach przeciążenia.

Przyszłe systemy mogą korzystać z szybszych ścieżek sieciowych i inteligentniejszych narzędzi testowych. Jednak kolejność podstawowych zdarzeń nadal będzie kluczowa.

Zespoły powinny usuwać jedno zmierzone wąskie gardło naraz. Powinny również potwierdzać każdą zmianę za pomocą testów odtwarzania i testów obciążeniowych.

• Zbuduj stałą ścieżkę zdarzeń dla każdego order booka
• Stosuj priorytet ceny i czasu, chyba że zasady stanowią inaczej
• Utrzymuj szybkie i łatwe do testowania kontrole ryzyka
• Skaluj bramy i feedy danych rynkowych niezależnie od rdzenia
• Przechowuj każdą decyzję do późniejszego odtworzenia

Ta równowaga tworzy system, któremu traderzy mogą ufać. Daje również operatorom jasną ścieżkę dalszego rozwoju.