Komunikasi Data dalam Sistem Algo Trading: Gambaran Keseluruhan Teknologi

Dalam dagangan algoritmik, perbezaan antara untung dan rugi boleh diukur dalam mikrosaat. Seni bina penghantaran data adalah salah satu faktor utama yang menentukan kecekapan sistem dagangan. Dalam artikel ini, kami akan menguraikan teknologi komunikasi di semua peringkat: daripada berinteraksi dengan bursa hinggalah kepada komunikasi dalaman antara perkhidmatan, penyimpanan, dan pengedaran data.

Artikel ini disusun mengikut peringkat—daripada "luaran" (protokol bursa) kepada "dalaman" (IPC, broker mesej, penyimpanan)—mencerminkan seni bina sebenar platform dagangan algoritmik.

1. Interaksi dengan Bursa: REST, WebSocket, FIX

1.1 REST API

REST adalah cara paling mudah dan paling biasa untuk berinteraksi dengan API bursa. Setiap permintaan adalah sambungan HTTP berasingan: jabat tangan TCP → jabat tangan TLS → hantar permintaan → terima respons → tutup sambungan.

Masalah REST untuk Dagangan:

Setiap permintaan menanggung overhed persediaan sambungan. Walaupun dengan HTTP keep-alive, model "permintaan-respons" bermakna anda tidak boleh menerima data lebih cepat daripada anda menghantar permintaan. Ini membawa kepada pengundian—kitaran tanpa henti pertanyaan "ada data baharu?" yang mencipta sehingga 80% beban pada pelayan bursa (menurut pembangun bursa kripto). Bursa mengenakan had kadar (biasanya 10–1200 permintaan seminit), menjadikan REST tidak sesuai untuk strategi frekuensi tinggi.

Bila REST sesuai digunakan: mengambil data sejarah (lilin, OHLCV), pengurusan akaun (baki, kedudukan), operasi bukan masa nyata (bot DCA, pengimbangan semula setiap jam).

1.2 WebSocket

WebSocket mewujudkan satu sambungan TCP berterusan di mana data mengalir secara dua hala. Ia bermula sebagai permintaan HTTP biasa dengan pengepala Upgrade, kemudian beralih kepada protokol pembingkaian dua arah (muatan boleh sama ada teks JSON atau binari).

Kelebihan untuk Dagangan:

Kelebihan utama adalah tiada overhed per permintaan. Setelah diwujudkan, data ditolak serta-merta oleh pelayan. Kependaman penghantaran data pasaran melalui WebSocket biasanya kurang daripada 50 ms dari get laluan bursa ke klien. Anda boleh melanggan 50+ simbol secara serentak melalui satu sambungan.

Perkara kritikal: pesanan melalui WebSocket. Ramai pedagang tidak tahu bahawa sesetengah bursa (Binance, HitBTC, Deribit, Bybit, dll.) membenarkan penghantaran pesanan melalui WebSocket, bukan hanya menerima data. Ini secara asasnya lebih pantas daripada REST kerana:

• Tiada jabat tangan TCP/TLS untuk setiap pesanan (sambungan sudah "hangat")
• Tiada overhed HTTP (pengepala, kuki, dll.)
• Model tak segerak: anda menghantar pesanan dan menerima pengesahan melalui WebSocket yang sama tanpa menyekat benang.

Menurut Deribit, WebSocket dan FIX sering mempunyai kelajuan pelaksanaan yang sama. REST sedikit lebih perlahan disebabkan prapemprosesan peringkat sambungan. Pesanan WebSocket mencecah barisan enjin padanan sama seperti pesanan FIX.

Masalah Pencampuran Konteks. Jika anda menghantar pesanan melalui REST tetapi menerima pemberitahuan pelaksanaan melalui WebSocket, keadaan perlumbaan berlaku: pemberitahuan WebSocket mungkin tiba sebelum permintaan REST selesai. Ini membawa kepada ketidakkonsistenan keadaan. Penyelesaiannya adalah menghantar pesanan melalui WebSocket yang sama, beralih sepenuhnya kepada model tak segerak.

1.3 Protokol FIX (Financial Information eXchange)

FIX adalah standard industri untuk dagangan elektronik, wujud sejak 1992 (dicipta oleh Fidelity Investments dan Salomon Brothers). Ia adalah protokol binari-atas-TCP yang direka khusus untuk dagangan.

Seni Bina FIX:

• Lapisan sesi — mengurus sambungan, degupan jantung, penomboran urutan, pemulihan jurang. Menjamin penghantaran dan susunan mesej.
• Lapisan aplikasi — logik perniagaan: jenis pesanan, laporan pelaksanaan, permintaan data pasaran.

Mesej FIX terdiri daripada pasangan "tag=nilai" yang dipisahkan oleh aksara SOH. Sebagai contoh, pesanan beli untuk 100 saham AAPL pada harga $150 kelihatan seperti ini:

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

Mengapa FIX lebih pantas daripada WebSocket: FIX adalah protokol TCP asli tanpa lapisan HTTP. AWS, dalam panduan pengoptimuman tick-to-trade untuk bursa kripto, secara eksplisit mengesyorkan FIX berbanding REST dan WebSocket bagi meminimumkan kependaman yang disebabkan protokol. FIX beroperasi pada peringkat mikrosaat, manakala WebSocket biasanya dalam milisaat.

Di mana FIX mendominasi: DMA (Akses Pasaran Terus) ke enjin padanan bursa, dagangan algoritmik dan HFT dalam ruang institusi, pengagregatan kecairan (broker utama yang menyambung ke berpuluh-puluh bank melalui FIX).

Batasan FIX: kerumitan integrasi, format mesej yang lapuk (tag-nilai teks kurang cekap berbanding format binari), halangan masuk yang tinggi. Dalam industri kripto, FIX disokong oleh bilangan bursa yang terhad.

1.4 SBE (Simple Binary Encoding) — FIX Evolusi

SBE adalah format pensirian binari yang dicipta oleh Kumpulan Kerja Prestasi Tinggi dalam FIX Trading Community. Misinya adalah untuk menggantikan format FIX teks dengan representasi binari padat untuk dagangan kependaman ultra-rendah.

Prinsip Utama SBE:

• Corak flyweight sifar-salin — pengekod dan penyahkod bertindak sebagai "templat" ke atas penimbal. Nilai ditulis terus tanpa salinan perantaraan (berbeza dengan Protobuf, yang memerlukan beberapa).
• Format kawat = format memori — data pada kawat kelihatan sama seperti dalam memori, meminimumkan overhed transformasi.
• Medan tetap dahulu, medan berubah kemudian — kekangan reka bentuk yang memberikan prestasi satu susunan magnitud lebih tinggi berbanding Protocol Buffers.

SBE + Aeron adalah kombinasi standard untuk sistem dagangan berprestasi tinggi. Aeron adalah sistem pemesejan sumber terbuka daripada Real Logic (dicipta oleh Martin Thompson, bekas CTO LMAX Exchange, dan Todd Montgomery, bekas CTO 29West/Ultra Messaging). Ia secara efektifnya adalah lapisan pengangkutan khusus untuk sistem kewangan yang bekerja melalui UDP dan memori kongsi dengan kependaman dalam mikrosaat satu digit. SBE mengendalikan pensirian, manakala Aeron mengurus penghantaran dengan kelewatan mikrosaat. Lebih lanjut mengenai Aeron dalam bahagian 3.1.

1.5 Jadual Perbandingan Protokol Bursa

2. Komunikasi Perkhidmatan Mikro Dalaman

Setelah data memasuki sistem anda dari bursa, pemprosesan dalaman bermula: penghuraian → strategi → keputusan → penghantaran pesanan. Pada setiap langkah, terdapat komunikasi antara perkhidmatan.

2.1 Penstriman Dua Hala gRPC (TCP)

gRPC adalah rangka kerja Google berasaskan HTTP/2 menggunakan Protocol Buffers untuk pensirian. Untuk dagangan algoritmik, penstriman dua hala amat penting—apabila klien dan pelayan menghantar strim mesej secara serentak melalui satu sambungan.

Mengapa gRPC sesuai untuk sistem dagangan:

• Protobuf adalah padat (3–10 kali lebih kecil daripada JSON)
• Multipleks HTTP/2 — beberapa strim melalui satu sambungan TCP
• Penatipan ketat melalui skema .proto yang mengesan ralat pada masa penyusunan
• Penjanaan kod untuk Python, Rust, Go, C++, Java, dll.
• Penstriman dua hala membolehkan corak "data pasaran turun, pesanan naik" melalui satu saluran.

Menurut SmartDev, 70% institusi kewangan yang menggunakan HFT berasaskan AI menggunakan gRPC atau TCP mentah untuk masa respons mikrosaat.

Contoh seni bina: Pengumpul Data Pasaran (Rust) → strim gRPC → Enjin Strategi (Python/Rust) → panggilan gRPC → Penghala Pesanan (Rust) → WebSocket/FIX → Bursa.

2.2 gRPC melalui Unix Domain Socket (UDS)

Jika perkhidmatan berjalan pada mesin yang sama (biasa untuk ko-lokasi), TCP adalah overhed yang tidak perlu. Unix Domain Socket (UDS) memintas keseluruhan tindanan rangkaian: tiada jabat tangan TCP, tiada penghalaan, tiada semakan checksum.

Penanda aras menunjukkan perbezaan yang ketara:

• gRPC melalui UDS: ~102 μs/permintaan (100K permintaan)
• gRPC melalui TCP: ~127 μs/permintaan (100K permintaan)
• Keuntungan UDS: ~20% pada mesej kecil, sehingga 50% pada mesej besar (100KB+).

Menurut F. Werner (MPI Heidelberg), membandingkan gRPC UDS dengan I/O penyekatan mentah melalui UDS, gRPC menambah kira-kira 10x overhed—median ~130 μs berbanding ~13 μs untuk UDS mentah. Ini adalah kos abstraksi (pembingkaian HTTP/2, pensirian protobuf).

Bila menggunakan gRPC+UDS: Komunikasi antara proses pada satu pelayan apabila kemudahan pembangun (skema, codegen) dihargai berbanding kependaman minimum mutlak. UDS juga menyediakan kelebihan keselamatan melalui kebenaran fail Unix.

Bila TIDAK menggunakan: Jika anda memerlukan kependaman <10 μs, memori kongsi atau UDS mentah tanpa gRPC adalah lebih baik. Sebagai rujukan: median UDS mentah ~13 μs, median gRPC UDS ~130 μs. Memori kongsi (Aeron IPC) kurang daripada 1 μs, penimbal gelang LMAX Disruptor sekitar 50–100 ns. Oleh itu gRPC+UDS adalah ~10x lebih perlahan daripada UDS mentah dan 100–1000x lebih perlahan daripada memori kongsi. Tetapi setiap langkah ke bawah dalam kependaman adalah langkah ke atas dalam kerumitan kod.

Reproduksi sendiri: Semua nombor kependaman IPC dalam bahagian ini boleh direproduksi dengan penanda aras teman sumber terbuka suenot/trading-ipc-bench — implementasi Python untuk TCP, UDS, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub, Memori Kongsi, dan perjalanan pulang-balik Named Pipe, mengukur kependaman p50/p95/p99/p99.9 dan daya pengeluaran pada perkakasan anda sendiri.

UDS mentah tanpa gRPC — jika overhed gRPC berlebihan, buangnya dan kekalkan hanya soket. Pilihan mengikut prestasi menurun:

• soket AF_UNIX + pensirian tersuai (SBE, FlatBuffers, MessagePack) — ~13 μs median, kawalan maksimum, kerumitan maksimum
• ZeroMQ IPC (ipc://) — ~50–100 μs, corak sedia ada (PUB/SUB, REQ/REP) tanpa boilerplate, menggunakan UDS di bawahnya
• nanomsg/NNG IPC — serupa dengan ZeroMQ, kependaman sedikit lebih baik pada mesej kecil (<64 KB)
• Cap'n Proto RPC melalui UDS — pensirian sifar-salin + abstraksi RPC, lebih pantas daripada gRPC, mempunyai skema

2.3 IPC Memori Kongsi

Untuk kependaman ultra-rendah pada hos yang sama, gunakan memori kongsi. Dua proses memetakan segmen RAM yang sama, dan data melepasi tanpa syscall (kecuali untuk persediaan awal).

Corak LMAX Disruptor (penimbal gelang dalam memori kongsi) mengendalikan ~6 juta peristiwa sesaat pada satu benang. Pendekatan ini adalah inti LMAX Exchange dan banyak sistem HFT.

Implementasi: Aeron IPC (Java/C++), Chronicle Queue (Java), penyelesaian berasaskan mmap tersuai (Rust/C++). IronSBE (implementasi Rust SBE) menyokong IPC memori kongsi dengan kependaman ~20 ns pada peringkat saluran SPSC.

3. Sistem Pengangkutan: Broker Mesej dan Pustaka

3.1 Aeron — Standard Emas

Aeron adalah sistem pengangkutan mesej sumber terbuka berprestasi tinggi yang dibangunkan oleh Real Logic. Penciptanya adalah Martin Thompson (bekas CTO LMAX) dan Todd Montgomery (bekas CTO 29West). Ia bermula pada 2014 untuk bursa utama AS dan kini mempunyai 70+ penyumbang dan 5000+ pelanggan GitHub.

Dalam praktik: Aeron bukan broker (seperti Kafka) mahupun pustaka soket (seperti ZeroMQ). Ia adalah lapisan pengangkutan yang direka untuk kependaman rendah yang boleh diramal. Ia berfungsi melalui UDP (rangkaian) dan memori kongsi (IPC), menyediakan penghantaran yang boleh dipercayai, susunan, dan kawalan aliran—perkara yang UDP mentah tidak ada. Fikirkan Aeron sebagai "TCP dengan kependaman UDP."

Ciri-ciri Aeron:

• Kependaman: <100 μs dalam awan, <18 μs pada perkakasan bare metal.
• Daya pengeluaran: >1J mesej/s pada kependaman mikrosaat.
• Puncak 20J+ mesej/s.
• Tanpa broker — tiada satu titik kegagalan.
• Menyokong unicast, multicast, dan IPC.
• Kawalan aliran dan pengesanan kehilangan terbina dalam.

Aeron Cluster — replikasi mesin keadaan bertoleransi-ralat (konsensus Raft) untuk logik dagangan yang konsisten dengan kependaman tambahan yang minimum.

Aeron Archive — kegigihan mesej pada kelajuan strim penuh dengan keupayaan main semula.

Aeron Sequencer — komponen terbaru ekosistem, direka untuk menyelaraskan pelbagai projek merentasi organisasi besar. Dibina di atas Pengangkutan Aeron dan Kluster Aeron. Ciri-ciri utama:

• Log teragih — urutan mesej panjang yang direplikasi merentasi pelbagai mesin untuk toleransi ralat
• Berbilang pembaca — pelbagai aplikasi secara serentak membaca dari log yang sama untuk tujuan berbeza
• Pasukan ternyahgandingan — pasukan kekal bebas sambil beroperasi dalam satu sistem yang diselaraskan
• Kes penggunaan sasaran: pemprosesan data pasaran, platform broker, enjin bursa

Perbandingan dengan Kafka: Kedua-duanya menggunakan log teragih, tetapi Aeron adalah untuk kependaman mikrosaat, manakala Kafka adalah untuk ketahanan dan daya pengeluaran milisaat. Aeron wujud untuk logik masa nyata; Kafka untuk saluran paip data dan analitik.

3.2 Apache Kafka

Apache Kafka adalah standard faktual untuk penstriman peristiwa pada skala. Ia bukan untuk laluan panas dagangan (kelewatan milisaat) tetapi tidak boleh diabaikan untuk:

• Pengagregatan data pasaran: mengumpul strim dari 100+ bursa ke dalam satu saluran paip.
• Penyumberan peristiwa: merekod setiap tindakan sistem sebagai topik peristiwa.
• CDC (Change Data Capture): menstrim perubahan DB dagangan ke analitik.
• Integrasi QuestDB: Kafka → QuestDB untuk analitik tick masa nyata.

Kependaman adalah 2–15 ms hujung-ke-hujung. Tidak boleh diterima untuk HFT, tetapi baik untuk strategi dengan ufuk >1s.

3.3 Redis Pub/Sub dan Strim

Redis adalah stor dalam memori yang juga berfungsi sebagai broker ringan.

Redis Pub/Sub — hantar-dan-lupakan; kependaman sub-milisaat. Sesuai untuk pemberitahuan masa nyata: kemas kini harga, isyarat strategi, amaran.

Redis Streams — menambah kegigihan dan kumpulan pengguna (mini-Kafka). Menyokong pembacaan sejarah dan ACK.

Redis lebih pantas daripada Kafka untuk mesej kecil (sub-ms), tetapi tidak mempunyai replikasi dan ketahanan berat Kafka.

3.4 NATS

NATS adalah sistem ultra-ringan dalam Go. Kependaman sub-ms, pub/sub terbina dalam, permintaan/balasan. NATS JetStream menambah kegigihan dan penghantaran tepat-sekali.

3.5 ZeroMQ dan nanomsg

Pustaka tanpa broker yang menyediakan abstraksi soket untuk komunikasi peer-to-peer. ZeroMQ mengendalikan 5J+ mesej/s dan telah diuji tempur sejak 2007. nanomsg (dan NNG) adalah "pengganti"nya dengan kependaman lebih baik pada mesej kecil (<64KB).

4. PUB/SUB Masa Nyata untuk Klien: Centrifugo

Centrifugo adalah pelayan PUB/SUB dihos sendiri dalam Go, dioptimumkan untuk penyiaran kepada ribuan/jutaan klien melalui WebSocket, SSE, atau gRPC.

Mengapa Centrifugo untuk Algo Trading:

• Mengendalikan 1J sambungan WebSocket dan 30J mesej/minit pada satu pelayan.
• Menyokong penstriman 60Hz.
• Pemampatan delta (algoritma Fossil) untuk meminimumkan trafik.
• Sempurna untuk "batu terakhir" ke papan pemuka web atau aplikasi mudah alih.

5. Stor Data Akses Masa Nyata

5.1 QuestDB — Siri Masa untuk Dagangan

QuestDB adalah pangkalan data siri masa sumber terbuka yang ditulis dalam Java (sifar-GC), C++, dan Rust.

• Pertanyaan: Pelaksanaan tervektorkan sub-ms melalui SIMD.
• SAMPLE BY/ASOF JOIN: Sambungan SQL mesra pedagang asli.
• WAL: Tambahan kependaman ultra-rendah.
• Digunakan oleh B3 (bursa saham Brazil).

5.2 Redis sebagai Lapisan Data

Biasanya lapisan tengah:

• Cache panas untuk akses harga O(1).
• Set terurut untuk buku pesanan.
• Skrip Lua untuk operasi atomik.

5.3 Penyelesaian Khusus: RayforceDB, AXL DB

Pangkalan data vektor berasaskan C minimalis (binari <1MB) dengan sifar kebergantungan dan pecutan SIMD. Fokus pada kependaman deterministik untuk HFT.

6. Pensirian: Protobuf vs SBE vs JSON

7. Seni Bina Rujukan

7.1 Arbitraj Kripto (Frekuensi Sederhana)

Bursa → Pengumpul (Rust) → Redis (Panas) → Strategi (Python) → gRPC → Penghala (Rust) → Bursa.

7.2 Pembuat Pasaran HFT (Ko-lokasi)

Suapan Bursa → NIC Pintas Kernel → Aeron IPC → Strategi (C++) → SBE → Aeron → Bursa.

8. Nasihat Praktikal

• <10 μs (HFT): FPGA, memori kongsi, SBE, Aeron IPC.
• 10–100 μs: Aeron (UDP), gRPC+UDS, ZeroMQ.
• 100 μs – 1 ms: gRPC (TCP), WebSocket, Protobuf.
• 1–10 ms (Frekuensi Sederhana): WebSocket, Kafka, Redis.
• >10 ms (Frekuensi Rendah / Swing): REST API sudah mencukupi. DCA, pengimbangan semula, pengurusan portfolio.

Jangan optimumkan apa yang bukan halangan. Jika strategi anda mengambil masa 50 ms untuk membuat keputusan, penjimatan 100 μs Aeron tidak akan memberi kesan. Seni bina hibrid adalah normal: gunakan REST untuk persediaan, gRPC untuk inti, dan WS untuk penghantaran.

Repositori Penanda Aras

Nombor kependaman yang dipetik sepanjang artikel ini boleh direproduksi dengan suenot/trading-ipc-bench — suite penanda aras Python sumber terbuka yang meliputi semua pengangkutan IPC utama yang dibincangkan di sini: TCP, UDS, Named Pipe, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub, dan Memori Kongsi.

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

Jalankan pada perkakasan anda — hasilnya akan berbeza daripada nombor dalam artikel ini bergantung kepada CPU, OS, versi kernel, dan penalaan anda. Itulah tujuannya.

Kesimpulan

Tiada teknologi komunikasi yang "sempurna". Setiap peringkat mempunyai keperluan unik: luaran (keserasian), dalaman (kependaman), saluran paip (kebolehpercayaan), dan klien (fleksibiliti). Seni bina adalah tentang memilih alat yang tepat untuk tugas tertentu.