Algo Trading Тутумдарындагы Дайындар Байланышы: Технологиялык Сереп

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

Макала деңгээлдер боюнча тартипке салынган — "сырткы" (биржа протоколдору) баштап "ички" (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 колдашуу жок, багыттоо жок, чекирейт эсептөө жок.

Бенчмарктар кыйла айырманы көрсөтөт:

• 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-ңузга, ОСго, ядро версиясына жана тууналанганга жараша бул макаладагы сандардан айырмаланат. Максаты да ушунда.

Корутунду

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