Algo Трейдинг Жүйелеріндегі Деректер Байланысы: Технологиялық Шолу

Алгоритмдік трейдингте пайда мен зиян арасындағы айырмашылықты микросекундпен өлшеуге болады. Деректерді тасымалдау архитектурасы трейдинг жүйесінің тиімділігін анықтайтын негізгі факторлардың бірі болып табылады. Бұл мақалада біз барлық деңгейлердегі байланыс технологияларын талдаймыз: биржамен өзара әрекеттесуден бастап, қызметтер арасындағы ішкі байланысқа, деректерді сақтауға және таратуға дейін.

Мақала деңгейлер бойынша реттелген — "сыртқыдан" (биржа хаттамалары) "ішкіге" (IPC, хабар брокерлері, сақтау) дейін — бұл алгоритмдік трейдинг платформасының нақты архитектурасын көрсетеді.

1. Биржамен Өзара Әрекеттесу: REST, WebSocket, FIX

1.1 REST API

REST — биржа API-мен өзара әрекеттесудің ең қарапайым және кең таралған тәсілі. Әрбір сұраныс жеке HTTP қосылымы болып табылады: TCP қолдасу → TLS қолдасу → сұраныс жіберу → жауап алу → қосылымды жабу.

Трейдинг үшін REST мәселелері:

Әрбір сұраныс қосылымды орнату шығынын алып жүреді. HTTP keep-alive болса да, "сұраныс-жауап" моделі сіз сұраныстарды жібере алатыннан тезірек деректер ала алмайтыныңызды білдіреді. Бұл polling-ке әкеледі — биржа серверлеріне жүктеменің 80%-ына дейін жасайтын "жаңа деректер бар ма?" деген сұрақтардың шексіз циклі (крипто биржа әзірлеушілерінің айтуынша). Биржалар жылдамдық шектеулерін енгізеді (әдетте минутына 10–1200 сұраныс), бұл REST-ті жоғары жиілікті стратегиялар үшін жарамсыз етеді.

REST қашан орынды: тарихи деректерді алу (свечалар, OHLCV), шот басқару (баланс, позициялар), нақты уақыттағы емес операциялар (DCA боттар, сағат сайынғы қайта теңгеру).

1.2 WebSocket

WebSocket деректер екі бағытта ағатын бір тұрақты TCP қосылымын орнатады. Ол Upgrade тақырыбы бар қарапайым HTTP сұранысы ретінде басталады, содан кейін екі бағытты фреймдеу хаттамасына ауысады (пайдалы жүктеме мәтіндік JSON немесе екілік болуы мүмкін).

Трейдинг үшін артықшылықтары:

Негізгі артықшылығы — әрбір сұраныс үшін шығынның болмауы. Қосылым орнатылғаннан кейін деректер сервер тарапынан бірден жіберіледі. Нарық деректерін WebSocket арқылы жеткізу кідірісі әдетте биржа шлюзінен клиентке дейін 50 мс-тан аз болады. Сіз бір қосылым арқылы бір мезгілде 50+ символға жазыла аласыз.

Маңызды тұс: WebSocket арқылы бұйрықтар. Көптеген трейдерлер кейбір биржалардың (Binance, HitBTC, Deribit, Bybit және т.б.) деректерді қабылдап қана қоймай, WebSocket арқылы бұйрықтар жіберуге де мүмкіндік беретінін білмейді. Бұл REST-тен түбегейлі тезірек, себебі:

• Әрбір бұйрық үшін TCP/TLS қолдасу қажет емес (қосылым "жылы" күйінде)
• HTTP шығыны жоқ (тақырыптар, cookies және т.б.)
• Асинхронды модель: сіз бұйрық жібересіз және расталуды сол WebSocket арқылы ағынды бұғаттамай аласыз.

Deribit мәліметтері бойынша, WebSocket пен FIX жиі бірдей орындалу жылдамдығына ие. REST қосылым деңгейіндегі алдын ала өңдеуге байланысты сәл баяу. WebSocket бұйрықтары FIX бұйрықтары сияқты matching engine кезегіне түседі.

Контексттерді Араластыру Мәселесі. Егер сіз бұйрықтарды REST арқылы жіберіп, орындалу туралы хабарламаларды WebSocket арқылы алсаңыз, race condition пайда болады: WebSocket хабарламасы REST сұранысы аяқталғанға дейін келуі мүмкін. Бұл күй сәйкессіздігіне әкеледі. Шешім — бұйрықтарды сол WebSocket арқылы жіберіп, толығымен асинхронды модельге көшу.

1.3 FIX Хаттамасы (Financial Information eXchange)

FIX — 1992 жылдан бері бар электронды трейдингтің салалық стандарты (Fidelity Investments және Salomon Brothers құрған). Бұл арнайы трейдинг үшін жасалған TCP үстіндегі екілік хаттама.

FIX Архитектурасы:

• Сессия деңгейі — қосылымды, heartbeat-терді, реттік нөмірлеуді, олқылықты қалпына келтіруді басқарады. Хабарламалардың жеткізілуі мен ретін кепілдендіреді.
• Қолданбалы деңгей — бизнес-логика: бұйрық түрлері, орындалу туралы есептер, нарық деректеріне сұраныстар.

FIX хабарламалары SOH таңбасымен бөлінген "тег=мән" жұптарынан тұрады. Мысалы, AAPL акцияларының 100 данасын $150-ға сатып алу бұйрығы былай көрінеді:

8=FIX.4.2|35=D|49=BUYER|56=SELLER|11=ORD1001|38=100|40=2|54=1|55=AAPL|44=150.00

FIX неге WebSocket-тен тезірек: FIX — HTTP қабаттарынсыз собственный TCP хаттамасы. AWS крипто биржалары үшін tick-to-trade оптимизация нұсқаулығында хаттамадан туындайтын кідірісті азайту үшін REST пен WebSocket-тің орнына нақты FIX-ті ұсынады. FIX микросекунд деңгейінде жұмыс істейді, ал WebSocket әдетте миллисекундта.

FIX қай жерде басым: биржаның matching engine-іне DMA (Direct Market Access), институционалдық ортадағы алгоритмдік және HFT трейдинг, өтімділікті біріктіру (prime broker-лер FIX арқылы ондаған банкпен қосылады).

FIX Шектеулері: интеграцияның күрделілігі, ескірген хабарлама форматы (мәтіндік тег-мәндер екілік форматтарға қарағанда тиімсіз), кіру тосқауылының жоғарылығы. Крипто индустриясында FIX шектеулі саны биржалармен ғана қолдау табады.

1.4 SBE (Simple Binary Encoding) — Эволюциялық FIX

SBE — FIX Trading Community құрамындағы High Performance Working Group құрған екілік сериялау форматы. Оның миссиясы — мәтіндік FIX форматын ультра-төмен кідірісті трейдинг үшін ықшам екілік ұсыныммен ауыстыру.

SBE-нің Негізгі Принциптері:

• Zero-copy flyweight үлгісі — кодерлер мен декодерлер буфер үстінде "үлгі" ретінде әрекет етеді. Мәндер аралық көшірмелерсіз тікелей жазылады (бірнешеуін талап ететін Protobuf-тан айырмашылығы).
• Wire форматы = жад форматы — желідегі деректер жадтағыдай көрінеді, бұл трансформация шығынын азайтады.
• Алдымен тұрақты өрістер, соңында айнымалы өрістер — Protocol Buffers-пен салыстырғанда бір реттік шамаға көбірек өнімділік беретін дизайн шектеуі.

SBE + Aeron — жоғары өнімді трейдинг жүйелері үшін стандартты комбинация. Aeron — Real Logic компаниясының ашық бастапқы кодты хабар алмасу жүйесі (Martin Thompson, LMAX Exchange-тің бұрынғы CTO-сы, және Todd Montgomery, 29West/Ultra Messaging-тің бұрынғы CTO-сы құрған). Ол іс жүзінде UDP және ортақ жад арқылы жалғыз цифрлы микросекунд кідірістерімен жұмыс істейтін қаржы жүйелеріне арналған мамандандырылған тасымал деңгейі. SBE сериялауды өңдейді, ал Aeron жеткізуді микросекундтық кідірістермен басқарады. Aeron туралы толығырақ 3.1 бөлімде.

1.5 Биржа Хаттамаларының Салыстырмалы Кестесі

2. Микросервистер Арасындағы Ішкі Байланыс

Деректер биржадан жүйеге түскеннен кейін, ішкі өңдеу басталады: талдау → стратегия → шешім → бұйрықты жіберу. Әрбір кезеңде қызметтер арасында байланыс болады.

2.1 gRPC Екі Бағытты Ағын (TCP)

gRPC — сериялау үшін Protocol Buffers қолданатын HTTP/2 негізіндегі Google фреймворкы. Алгоритмдік трейдинг үшін екі бағытты ағын әсіресе маңызды — клиент пен сервер бір қосылым арқылы бір мезгілде хабарлама ағындарын жібереді.

gRPC трейдинг жүйелеріне неге сай келеді:

• Protobuf ықшам (JSON-нан 3–10 есе кіші)
• HTTP/2 мультиплекстеу — бір TCP қосылымы арқылы бірнеше ағын
• .proto схемалары арқылы қатаң типтеу қателерді компиляция кезінде ұстайды
• Python, Rust, Go, C++, Java және т.б. үшін код генерациясы
• Екі бағытты ағын бір арна арқылы "нарық деректері төмен, бұйрықтар жоғары" үлгісін мүмкін етеді.

SmartDev мәліметтері бойынша, ЖИ негізіндегі HFT қолданатын қаржы институттарының 70%-ы микросекундтық жауап уақыты үшін gRPC немесе таза TCP қолданады.

Архитектура мысалы: Market Data Collector (Rust) → gRPC ағыны → Strategy Engine (Python/Rust) → gRPC шақыруы → Order Router (Rust) → WebSocket/FIX → Биржа.

2.2 Unix Domain Socket (UDS) арқылы gRPC

Егер қызметтер бір машинада жұмыс істесе (co-location үшін типтік жағдай), TCP қажетсіз шығын болады. Unix Domain Socket (UDS) бүкіл желі стегін айналып өтеді: TCP қолдасу жоқ, бағыттау жоқ, checksum есептеу жоқ.

Бенчмарктер айтарлықтай айырмашылықты көрсетеді:

• UDS арқылы gRPC: ~102 мкс/сұраныс (100 мың сұраныс)
• TCP арқылы gRPC: ~127 мкс/сұраныс (100 мың сұраныс)
• UDS-тің пайдасы: кіші хабарламаларда ~20%, үлкендерінде (100КБ+) 50%-ға дейін.

F. Werner (MPI Heidelberg) мәліметтері бойынша, gRPC UDS-ті UDS арқылы таза бұғаттаушы I/O-мен салыстырғанда, gRPC шамамен 10 есе шығын қосады — таза UDS үшін ~13 мкс-пен салыстырғанда медиана ~130 мкс. Бұл абстракцияның бағасы (HTTP/2 фреймдеу, protobuf сериялау).

gRPC+UDS қашан қолдану керек: Бір серверде процестер арасындағы байланыс, әзірлеушінің ыңғайлылығы (схема, кодогенерация) абсолютті минималды кідірістен жоғары бағаланғанда. UDS сонымен қатар Unix файл рұқсаттары арқылы қауіпсіздік артықшылықтарын береді.

Қашан ҚОЛДАНБАУ керек: Егер сізге <10 мкс кідіріс қажет болса, ортақ жад немесе gRPC-сіз таза UDS жақсырақ. Анықтама үшін: таза UDS медианасы ~13 мкс, gRPC UDS медианасы ~130 мкс. Ортақ жад (Aeron IPC) 1 мкс-тан төмен, LMAX Disruptor сақина буфері шамамен 50–100 нс. Осылайша gRPC+UDS таза UDS-тен ~10 есе, ортақ жадтан 100–1000 есе баяу. Бірақ кідірістегі әрбір қадам төмен код күрделілігінде жоғары қадам болып табылады.

Өзіңіз қайталаңыз: Осы бөлімдегі барлық IPC кідіріс сандары ашық бастапқы кодты серіктес бенчмаркпен қайталанады — suenot/trading-ipc-bench — TCP, UDS, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub, Ортақ жад және Named Pipe round-trip-терінің Python іске асыруларын қамтиды, p50/p95/p99/p99.9 кідірісі мен өткізу қабілетін өз жабдығыңызда өлшейді.

gRPC-сіз таза UDS — егер gRPC шығыны шамадан тыс болса, оны алып тастап, тек сокетті қалдырыңыз. Өнімділіктің кему ретімен нұсқалар:

• AF_UNIX сокеттері + пайдаланушылық сериялау (SBE, FlatBuffers, MessagePack) — ~13 мкс медиана, максималды бақылау, максималды күрделілік
• ZeroMQ IPC (ipc://) — ~50–100 мкс, boilerplate-сіз дайын үлгілер (PUB/SUB, REQ/REP), капот астында UDS қолданады
• nanomsg/NNG IPC — ZeroMQ-ге ұқсас, кіші хабарламаларда (<64 КБ) сәл жақсырақ кідіріс
• Cap'n Proto RPC UDS үстінде — zero-copy сериялау + RPC абстракциясы, gRPC-ден тезірек, схемасы бар

2.3 Ортақ Жад IPC

Сол хостта ультра-төмен кідіріс үшін ортақ жадты қолданыңыз. Екі процесс сол RAM сегментін көрсетеді, деректер syscall-сыз өтеді (бастапқы орнатудан басқа).

LMAX Disruptor үлгісі (ортақ жадтағы сақина буфері) бір ағында секундына ~6 миллион оқиғаны өңдейді. Бұл тәсіл LMAX Exchange-тің және көптеген HFT жүйелерінің жүрегі болып табылады.

Іске асырулар: Aeron IPC (Java/C++), Chronicle Queue (Java), mmap негізіндегі пайдаланушылық шешімдер (Rust/C++). IronSBE (Rust-тағы SBE іске асыруы) SPSC арна деңгейінде ~20 нс кідіріспен ортақ жад IPC-ін қолдайды.

3. Тасымал Жүйелері: Хабар Брокерлері мен Кітапханалар

3.1 Aeron — Алтын Стандарт

Aeron — Real Logic әзірлеген ашық бастапқы кодты жоғары өнімді хабар тасымалдау жүйесі. Оның авторлары — Martin Thompson (бұрынғы LMAX CTO-сы) және Todd Montgomery (бұрынғы 29West CTO-сы). Ол 2014 жылы ірі АҚШ биржасы үшін басталды, қазір 70+ үлес қосушысы және 5000+ GitHub жазылушысы бар.

Практикада: Aeron брокер де (Kafka сияқты), сокет кітапханасы да (ZeroMQ сияқты) емес. Бұл болжамды төмен кідіріс үшін жасалған тасымал деңгейі. Ол UDP (желі) және ортақ жад (IPC) арқылы жұмыс істейді, сенімді жеткізуді, реттеуді және ағын бақылауын қамтамасыз етеді — таза UDP-де жоқ нәрселер. Aeron-ды "UDP кідірісі бар TCP" ретінде елестетіңіз.

Aeron Сипаттамалары:

• Кідіріс: бұлтта <100 мкс, физикалық серверде <18 мкс.
• Өткізу қабілеті: микросекундтық кідірісте >1М хабарлама/с.
• Шыңы 20М+ хабарлама/с.
• Брокерсіз — бір сәтсіздік нүктесі жоқ.
• Unicast, multicast және IPC-ті қолдайды.
• Кірістірілген ағын бақылауы мен жоғалуды анықтау.

Aeron Cluster — минималды қосымша кідіріспен тұрақты трейдинг логикасы үшін ақаудан төзімді күй машинасын репликациялау (Raft консенсусы).

Aeron Archive — қайта ойнату мүмкіндігімен толық ағын жылдамдығында хабарламаларды сақтау.

Aeron Sequencer — экожүйенің ең жаңа компоненті, ірі ұйымдардағы бірнеше жобаны үйлестіруге арналған. Aeron Transport пен Aeron Cluster негізінде құрылған. Негізгі сипаттамалары:

• Таралған журнал — ақаудан төзімділік үшін бірнеше машинаға репликацияланған хабарламалардың ұзақ тізбегі
• Бірнеше оқырман — бірнеше қолданба әртүрлі мақсаттар үшін сол журналдан бір мезгілде оқиды
• Ажыратылған командалар — командалар бір үйлестірілген жүйе шеңберінде жұмыс істей отырып тәуелсіз болып қалады
• Мақсатты қолдану жағдайлары: нарық деректерін өңдеу, брокер платформалары, биржа қозғалтқыштары

Kafka-мен Салыстыру: Екеуі де таралған журналды қолданады, бірақ Aeron микросекундтық кідіріс үшін, ал Kafka миллисекундтық ұзақтық пен өткізу қабілеті үшін. Aeron нақты уақыттағы логика үшін бар; Kafka деректер құбырлары мен аналитика үшін.

3.2 Apache Kafka

Apache Kafka — ауқымды оқиға ағынын жіберудің іс жүзіндегі стандарты. Ол трейдингтің hot path-ы үшін емес (миллисекундтық кідірістер), бірақ мыналар үшін таптырмас:

• Нарық деректерін біріктіру: 100+ биржадан ағындарды бір құбырға жинау.
• Оқиға көзі (event sourcing): жүйенің әрбір әрекетін оқиға тақырыбы ретінде жазу.
• CDC (Change Data Capture): трейдинг дерекқорының өзгерістерін аналитикаға ағынмен жіберу.
• QuestDB интеграциясы: нақты уақыттағы тик аналитикасы үшін Kafka → QuestDB.

Кідіріс соңынан соңына дейін 2–15 мс. HFT үшін жарамсыз, бірақ >1с көкжиегі бар стратегиялар үшін жарайды.

3.3 Redis Pub/Sub және Streams

Redis — жеңіл брокер ретінде де жұмыс істейтін жадтағы қойма.

Redis Pub/Sub — жіберу-және-ұмыту (fire-and-forget); миллисекундтан төмен кідіріс. Нақты уақыттағы хабарламалар үшін тамаша: баға жаңартулары, стратегия сигналдары, ескертулер.

Redis Streams — тұрақтылық пен тұтынушы топтарын қосады (мини-Kafka). Тарихты оқуды және ACK-терді қолдайды.

Redis кіші хабарламаларда Kafka-дан тезірек (мс-тан төмен), бірақ Kafka-ның ауыр репликациясы мен ұзақтығы жетіспейді.

3.4 NATS

NATS — Go тіліндегі ультражеңіл жүйе. Мс-тан төмен кідіріс, кірістірілген pub/sub, request/reply. NATS JetStream тұрақтылық пен exactly-once жеткізуді қосады.

3.5 ZeroMQ және nanomsg

Peer-to-peer байланыс үшін сокет абстракцияларын беретін брокерсіз кітапханалар. ZeroMQ секундына 5М+ хабарламаны өңдейді және 2007 жылдан бері іс жүзінде сыналған. nanomsg (және NNG) — оның кіші хабарламаларда (<64КБ) жақсырақ кідірісі бар "мұрагері".

4. Клиенттер үшін Нақты Уақыттағы PUB/SUB: Centrifugo

Centrifugo — WebSocket, SSE немесе gRPC арқылы миллиондаған клиенттерге тарату үшін оңтайландырылған, Go тіліндегі өз-серверде орналастырылатын PUB/SUB сервері.

Centrifugo неге Algo Trading үшін жарамды:

• Бір серверде 1М WebSocket қосылымын және минутына 30М хабарламаны өңдейді.
• 60Гц ағынды қолдайды.
• Трафикті азайту үшін дельта сығымдау (Fossil алгоритмі).
• Веб-дашбордтарға немесе мобильді қосымшаларға дейінгі "соңғы миля" үшін тамаша.

5. Нақты Уақыттағы Қолжетімділік Деректер Қоймалары

5.1 QuestDB — Трейдинг үшін Уақыт Қатары

QuestDB — Java (zero-GC), C++ және Rust тілдерінде жазылған ашық бастапқы кодты уақыт қатары дерекқоры.

• Сұраныстар: SIMD арқылы миллисекундтан төмен векторланған орындалу.
• SAMPLE BY/ASOF JOIN: собственный трейдерге ыңғайлы SQL кеңейтулері.
• WAL: ультра-төмен кідірісті жалғау.
• B3 (Бразилия қор биржасы) қолданады.

5.2 Деректер Деңгейі ретінде Redis

Әдетте аралық деңгей:

• O(1) баға қолжетімділігі үшін ыстық кэш.
• Тапсырыс кітаптары үшін сұрыпталған жиындар.
• Атомдық операциялар үшін Lua скриптері.

5.3 Мамандандырылған Шешімдер: RayforceDB, AXL DB

Тәуелділіктерсіз және SIMD үдетуімен C тіліндегі минималистік вектор дерекқорлары (екілік файл <1МБ). HFT үшін детерминистік кідіріске бағдарлау.

6. Сериялау: Protobuf vs SBE vs JSON

7. Анықтамалық Архитектуралар

7.1 Крипто Арбитраж (Орташа Жиілік)

Биржалар → Collector (Rust) → Redis (Hot) → Strategy (Python) → gRPC → Router (Rust) → Биржа.

7.2 HFT Market Making (Co-location)

Exchange Feed → Kernel Bypass NIC → Aeron IPC → Strategy (C++) → SBE → Aeron → Биржа.

8. Практикалық Кеңестер

• <10 мкс (HFT): FPGA, ортақ жад, SBE, Aeron IPC.
• 10–100 мкс: Aeron (UDP), gRPC+UDS, ZeroMQ.
• 100 мкс – 1 мс: gRPC (TCP), WebSocket, Protobuf.
• 1–10 мс (Орташа Жиілік): WebSocket, Kafka, Redis.
• >10 мс (Төмен Жиілік / Swing): REST API жеткілікті. DCA, қайта теңгеру, портфель басқару.

Тар жер болмайтын нәрсені оңтайландырмаңыз. Егер стратегияңыз шешім қабылдауға 50 мс жұмсаса, Aeron-ның 100 мкс үнемдеуі маңызды болмайды. Гибридті архитектуралар қалыпты жағдай: орнатуға REST, жүрекке gRPC, жеткізуге WS қолданыңыз.

Бенчмарк Репозиторийі

Осы мақалада келтірілген кідіріс сандарын suenot/trading-ipc-bench — мұнда талқыланған барлық негізгі IPC тасымалдарын қамтитын ашық бастапқы кодты Python бенчмарк жиынтығымен — қайталауға болады: TCP, UDS, Named Pipe, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub және Ортақ жад.

git clone https://github.com/suenot/trading-ipc-bench
cd trading-ipc-bench
pip install -r requirements.txt
python run_all.py   # runs all 8 transports, saves results to results/
python report.py    # prints a summary table + ASCII latency chart

Оны өз жабдығыңызда іске қосыңыз — нәтижелер сіздің CPU-ыңызға, ОЖ-ге, ядро нұсқасына және баптауға байланысты осы мақаладағы сандардан ерекшеленеді. Мақсаты да осында.

Қорытынды

"Мінсіз" байланыс технологиясы жоқ. Әрбір деңгейдің өзіндік талаптары бар: сыртқы (үйлесімділік), ішкі (кідіріс), құбыр (сенімділік) және клиент (икемділік). Архитектура — нақты тапсырма үшін дұрыс құралды таңдау туралы.