Truyền Thông Dữ Liệu trong Hệ Thống Giao Dịch Thuật Toán: Tổng Quan Công Nghệ

Trong giao dịch thuật toán, sự khác biệt giữa lợi nhuận và thua lỗ có thể được đo bằng đơn vị micro giây. Kiến trúc truyền dữ liệu là một trong những yếu tố then chốt quyết định hiệu quả của hệ thống giao dịch. Trong bài viết này, chúng tôi sẽ phân tích các công nghệ truyền thông ở tất cả các cấp độ: từ tương tác với sàn giao dịch đến giao tiếp nội bộ giữa các dịch vụ, lưu trữ và phân phối dữ liệu.

Bài viết được tổ chức theo các cấp độ — từ "bên ngoài" (giao thức sàn giao dịch) đến "bên trong" (IPC, message broker, lưu trữ) — phản ánh kiến trúc thực tế của một nền tảng giao dịch thuật toán.

1. Tương Tác Với Sàn Giao Dịch: REST, WebSocket, FIX

1.1 REST API

REST là cách dễ nhất và phổ biến nhất để tương tác với API sàn giao dịch. Mỗi yêu cầu là một kết nối HTTP riêng biệt: bắt tay TCP → bắt tay TLS → gửi yêu cầu → nhận phản hồi → đóng kết nối.

Các vấn đề của REST trong Giao Dịch:

Mỗi yêu cầu đều mang overhead thiết lập kết nối. Ngay cả với HTTP keep-alive, mô hình "yêu cầu-phản hồi" có nghĩa là bạn không thể nhận dữ liệu nhanh hơn tốc độ gửi yêu cầu. Điều này dẫn đến polling — một vòng lặp vô tận của các truy vấn "có dữ liệu mới không?" tạo ra đến 80% tải trên máy chủ sàn giao dịch (theo các nhà phát triển sàn giao dịch crypto). Các sàn giao dịch áp đặt giới hạn tốc độ (thường 10–1200 yêu cầu mỗi phút), khiến REST không phù hợp cho các chiến lược tần suất cao.

Khi nào REST phù hợp: tải dữ liệu lịch sử (nến, OHLCV), quản lý tài khoản (số dư, vị thế), các hoạt động không thời gian thực (bot DCA, tái cân bằng theo giờ).

1.2 WebSocket

WebSocket thiết lập một kết nối TCP liên tục qua đó dữ liệu chảy theo hai chiều. Nó bắt đầu như một yêu cầu HTTP thông thường với header Upgrade, sau đó chuyển sang giao thức framing hai chiều (payload có thể là JSON văn bản hoặc nhị phân).

Ưu Điểm cho Giao Dịch:

Ưu điểm chính là không có overhead cho mỗi yêu cầu. Sau khi thiết lập, dữ liệu được máy chủ đẩy ngay lập tức. Độ trễ phân phối dữ liệu thị trường qua WebSocket thường dưới 50 ms từ gateway sàn giao dịch đến client. Bạn có thể đăng ký 50+ symbol cùng lúc qua một kết nối duy nhất.

Một điểm quan trọng: đặt lệnh qua WebSocket. Nhiều trader không biết rằng một số sàn giao dịch (Binance, HitBTC, Deribit, Bybit, v.v.) cho phép gửi lệnh qua WebSocket, không chỉ nhận dữ liệu. Điều này về cơ bản nhanh hơn REST vì:

• Không có bắt tay TCP/TLS cho mỗi lệnh (kết nối đã "ấm")
• Không có overhead HTTP (headers, cookies, v.v.)
• Mô hình bất đồng bộ: bạn gửi lệnh và nhận xác nhận qua cùng WebSocket mà không chặn luồng.

Theo Deribit, WebSocket và FIX thường có tốc độ thực thi giống nhau. REST chậm hơn một chút do tiền xử lý ở cấp kết nối. Lệnh WebSocket vào hàng đợi matching engine giống như lệnh FIX.

Vấn Đề Trộn Lẫn Context. Nếu bạn gửi lệnh qua REST nhưng nhận thông báo thực thi qua WebSocket, một race condition xảy ra: thông báo WebSocket có thể đến trước khi yêu cầu REST hoàn thành. Điều này dẫn đến mâu thuẫn trạng thái. Giải pháp là gửi lệnh qua cùng WebSocket, chuyển hoàn toàn sang mô hình bất đồng bộ.

1.3 Giao Thức FIX (Financial Information eXchange)

FIX là tiêu chuẩn công nghiệp cho giao dịch điện tử, tồn tại từ năm 1992 (được tạo bởi Fidelity Investments và Salomon Brothers). Đây là giao thức nhị phân-qua-TCP được thiết kế đặc biệt cho giao dịch.

Kiến Trúc FIX:

• Tầng phiên — quản lý kết nối, heartbeat, đánh số thứ tự, phục hồi khoảng trống. Đảm bảo giao hàng và thứ tự tin nhắn.
• Tầng ứng dụng — logic nghiệp vụ: loại lệnh, báo cáo thực thi, yêu cầu dữ liệu thị trường.

Tin nhắn FIX bao gồm các cặp "tag=value" được phân cách bằng ký tự SOH. Ví dụ, lệnh mua 100 cổ phiếu AAPL ở giá $150 trông như sau:

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

Tại sao FIX nhanh hơn WebSocket: FIX là giao thức TCP gốc không có các tầng HTTP. AWS, trong hướng dẫn tối ưu hóa tick-to-trade cho sàn giao dịch crypto, khuyến nghị rõ ràng FIX thay vì REST và WebSocket để giảm thiểu độ trễ do giao thức gây ra. FIX hoạt động ở mức micro giây, trong khi WebSocket thường ở mức mili giây.

Nơi FIX chiếm ưu thế: DMA (Direct Market Access) đến matching engine của sàn giao dịch, giao dịch thuật toán và HFT trong không gian tổ chức, tổng hợp thanh khoản (prime broker kết nối với hàng chục ngân hàng qua FIX).

Giới Hạn của FIX: độ phức tạp tích hợp, định dạng tin nhắn lỗi thời (tag-value văn bản kém hiệu quả hơn định dạng nhị phân), rào cản gia nhập cao. Trong ngành crypto, FIX chỉ được hỗ trợ bởi một số ít sàn giao dịch.

1.4 SBE (Simple Binary Encoding) — FIX Tiến Hóa

SBE là định dạng tuần tự hóa nhị phân được tạo bởi High Performance Working Group trong FIX Trading Community. Sứ mệnh của nó là thay thế định dạng FIX văn bản bằng biểu diễn nhị phân nhỏ gọn cho giao dịch độ trễ cực thấp.

Các Nguyên Tắc Chính của SBE:

• Mẫu flyweight zero-copy — bộ mã hóa và giải mã hoạt động như "mẫu" trên một bộ đệm. Các giá trị được ghi trực tiếp mà không có bản sao trung gian (không giống Protobuf đòi hỏi vài bản sao).
• Định dạng wire = định dạng bộ nhớ — dữ liệu trên wire trông giống hệt như trong bộ nhớ, giảm thiểu overhead chuyển đổi.
• Các trường cố định trước, trường biến đổi sau — một ràng buộc thiết kế mang lại hiệu suất cao hơn gấp bậc so với Protocol Buffers.

SBE + Aeron là sự kết hợp tiêu chuẩn cho các hệ thống giao dịch hiệu suất cao. Aeron là hệ thống truyền tin nguồn mở từ Real Logic (được tạo bởi Martin Thompson, cựu CTO của LMAX Exchange, và Todd Montgomery, cựu CTO của 29West/Ultra Messaging). Đây thực chất là một tầng vận chuyển chuyên biệt cho hệ thống tài chính hoạt động qua UDP và bộ nhớ chia sẻ với độ trễ ở mức micro giây đơn. SBE xử lý tuần tự hóa, trong khi Aeron quản lý phân phối với độ trễ micro giây. Thêm thông tin về Aeron trong mục 3.1.

1.5 Bảng So Sánh Giao Thức Sàn Giao Dịch

2. Giao Tiếp Nội Bộ Giữa Các Microservice

Sau khi dữ liệu vào hệ thống từ sàn giao dịch, quá trình xử lý nội bộ bắt đầu: phân tích → chiến lược → quyết định → gửi lệnh. Ở mỗi bước, có giao tiếp giữa các dịch vụ.

2.1 gRPC Streaming Hai Chiều (TCP)

gRPC là framework của Google dựa trên HTTP/2 sử dụng Protocol Buffers để tuần tự hóa. Đối với giao dịch thuật toán, streaming hai chiều đặc biệt quan trọng — khi client và server đồng thời gửi luồng tin nhắn qua một kết nối.

Tại sao gRPC phù hợp với hệ thống giao dịch:

• Protobuf nhỏ gọn (nhỏ hơn JSON 3–10 lần)
• HTTP/2 multiplexing — nhiều luồng trên một kết nối TCP
• Gõ phím nghiêm ngặt qua schema .proto phát hiện lỗi tại thời điểm biên dịch
• Tạo code cho Python, Rust, Go, C++, Java, v.v.
• Streaming hai chiều cho phép mẫu "dữ liệu thị trường xuống, lệnh lên" qua một kênh.

Theo SmartDev, 70% tổ chức tài chính triển khai HFT dựa trên AI sử dụng gRPC hoặc TCP thuần cho thời gian phản hồi micro giây.

Ví dụ kiến trúc: Market Data Collector (Rust) → luồng gRPC → Strategy Engine (Python/Rust) → gọi gRPC → Order Router (Rust) → WebSocket/FIX → Sàn giao dịch.

2.2 gRPC qua Unix Domain Socket (UDS)

Nếu các dịch vụ chạy trên cùng máy (thông thường với co-location), TCP là overhead không cần thiết. Unix Domain Socket (UDS) bỏ qua toàn bộ network stack: không có bắt tay TCP, không định tuyến, không kiểm tra checksum.

Benchmark cho thấy sự khác biệt đáng kể:

• gRPC qua UDS: ~102 μs/yêu cầu (100K yêu cầu)
• gRPC qua TCP: ~127 μs/yêu cầu (100K yêu cầu)
• Lợi thế UDS: ~20% trên tin nhắn nhỏ, lên đến 50% trên tin nhắn lớn (100KB+).

Theo F. Werner (MPI Heidelberg), so sánh gRPC UDS với raw blocking I/O qua UDS, gRPC thêm khoảng 10 lần overhead — trung vị ~130 μs so với ~13 μs cho UDS thuần. Đây là chi phí của sự trừu tượng hóa (HTTP/2 framing, tuần tự hóa protobuf).

Khi nào dùng gRPC+UDS: Giao tiếp giữa các tiến trình trên một máy chủ khi sự tiện lợi cho nhà phát triển (schema, codegen) được đánh giá cao hơn độ trễ tối thiểu tuyệt đối. UDS cũng cung cấp lợi thế bảo mật qua quyền file Unix.

Khi KHÔNG nên dùng: Nếu bạn cần độ trễ <10 μs, bộ nhớ chia sẻ hoặc UDS thuần không có gRPC là tốt hơn. Để tham khảo: UDS thuần trung vị ~13 μs, gRPC UDS trung vị ~130 μs. Bộ nhớ chia sẻ (Aeron IPC) dưới 1 μs, ring buffer LMAX Disruptor khoảng 50–100 ns. Do đó gRPC+UDS chậm hơn ~10 lần so với UDS thuần và 100–1000 lần chậm hơn bộ nhớ chia sẻ. Nhưng mỗi bước giảm độ trễ là một bước tăng độ phức tạp code.

Tự tái tạo: Tất cả các con số độ trễ IPC trong mục này có thể tái tạo với benchmark nguồn mở suenot/trading-ipc-bench — các triển khai Python của TCP, UDS, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub, Shared Memory và Named Pipe round-trip, đo p50/p95/p99/p99.9 độ trễ và thông lượng trên phần cứng của bạn.

UDS thuần không có gRPC — nếu overhead gRPC quá lớn, hãy loại bỏ nó và chỉ giữ socket. Các tùy chọn theo thứ tự hiệu suất giảm dần:

• Socket AF_UNIX + tuần tự hóa tùy chỉnh (SBE, FlatBuffers, MessagePack) — trung vị ~13 μs, kiểm soát tối đa, độ phức tạp tối đa
• ZeroMQ IPC (ipc://) — ~50–100 μs, các mẫu sẵn có (PUB/SUB, REQ/REP) không cần boilerplate, sử dụng UDS bên dưới
• nanomsg/NNG IPC — tương tự ZeroMQ, độ trễ tốt hơn một chút trên tin nhắn nhỏ (<64 KB)
• Cap'n Proto RPC qua UDS — tuần tự hóa zero-copy + trừu tượng hóa RPC, nhanh hơn gRPC, có schema

2.3 Shared Memory IPC

Để đạt độ trễ cực thấp trên cùng máy chủ, sử dụng bộ nhớ chia sẻ. Hai tiến trình ánh xạ cùng một phân đoạn RAM, và dữ liệu truyền qua mà không cần syscall (ngoại trừ thiết lập ban đầu).

Mẫu LMAX Disruptor (ring buffer trong bộ nhớ chia sẻ) xử lý ~6 triệu sự kiện mỗi giây trên một luồng đơn. Cách tiếp cận này là trái tim của LMAX Exchange và nhiều hệ thống HFT.

Các triển khai: Aeron IPC (Java/C++), Chronicle Queue (Java), giải pháp dựa trên mmap tùy chỉnh (Rust/C++). IronSBE (triển khai SBE Rust) hỗ trợ shared memory IPC với độ trễ ~20 ns ở cấp kênh SPSC.

3. Hệ Thống Vận Chuyển: Message Broker và Thư Viện

3.1 Aeron — Tiêu Chuẩn Vàng

Aeron là hệ thống vận chuyển tin nhắn hiệu suất cao nguồn mở được phát triển bởi Real Logic. Những người tạo ra nó là Martin Thompson (cựu CTO LMAX) và Todd Montgomery (cựu CTO 29West). Nó bắt đầu vào năm 2014 cho một sàn giao dịch lớn của Mỹ và hiện có 70+ cộng tác viên và 5000+ người theo dõi GitHub.

Trên thực tế: Aeron không phải là broker (như Kafka) cũng không phải thư viện socket (như ZeroMQ). Đây là tầng vận chuyển được thiết kế cho độ trễ thấp có thể dự đoán. Nó hoạt động qua UDP (mạng) và bộ nhớ chia sẻ (IPC), cung cấp phân phối đáng tin cậy, thứ tự và kiểm soát luồng — những thứ mà UDP thuần thiếu. Hãy nghĩ về Aeron như "TCP với độ trễ UDP."

Đặc Tính Aeron:

• Độ trễ: <100 μs trên cloud, <18 μs trên bare metal.
• Thông lượng: >1M tin nhắn/s ở độ trễ micro giây.
• Đỉnh 20M+ tin nhắn/s.
• Không có broker — không có điểm lỗi đơn.
• Hỗ trợ unicast, multicast và IPC.
• Kiểm soát luồng và phát hiện mất gói tích hợp.

Aeron Cluster — sao chép máy trạng thái chịu lỗi (đồng thuận Raft) cho logic giao dịch nhất quán với độ trễ thêm tối thiểu.

Aeron Archive — lưu trữ tin nhắn ở tốc độ luồng đầy đủ với khả năng phát lại.

Aeron Sequencer — thành phần mới nhất của hệ sinh thái, được thiết kế để điều phối nhiều dự án trong các tổ chức lớn. Được xây dựng trên Aeron Transport và Aeron Cluster. Đặc tính chính:

• Distributed log — một chuỗi dài các tin nhắn được sao chép trên nhiều máy để chịu lỗi
• Multiple readers — nhiều ứng dụng đọc đồng thời từ cùng một log cho các mục đích khác nhau
• Decoupled teams — các nhóm vẫn độc lập trong khi hoạt động trong một hệ thống điều phối duy nhất
• Trường hợp sử dụng mục tiêu: xử lý dữ liệu thị trường, nền tảng môi giới, engine sàn giao dịch

So Sánh với Kafka: Cả hai đều sử dụng distributed log, nhưng Aeron cho độ trễ micro giây, trong khi Kafka cho độ bền và thông lượng mili giây. Aeron tồn tại cho logic thời gian thực; Kafka cho data pipeline và phân tích.

3.2 Apache Kafka

Apache Kafka là tiêu chuẩn thực tế cho event streaming ở quy mô lớn. Không dành cho hot path giao dịch (độ trễ mili giây) nhưng không thể thiếu cho:

• Tổng hợp dữ liệu thị trường: thu thập luồng từ 100+ sàn giao dịch vào một pipeline.
• Event sourcing: ghi lại mọi hành động hệ thống như một topic sự kiện.
• CDC (Change Data Capture): streaming các thay đổi DB giao dịch đến analytics.
• Tích hợp QuestDB: Kafka → QuestDB cho analytics tick thời gian thực.

Độ trễ là 2–15 ms end-to-end. Không chấp nhận được cho HFT, nhưng ổn cho các chiến lược có horizon >1s.

3.3 Redis Pub/Sub và Streams

Redis là in-memory store cũng hoạt động như một broker nhẹ.

Redis Pub/Sub — fire-and-forget; độ trễ dưới mili giây. Lý tưởng cho thông báo thời gian thực: cập nhật giá, tín hiệu chiến lược, cảnh báo.

Redis Streams — thêm lưu trữ và consumer group (mini-Kafka). Hỗ trợ đọc lịch sử và ACK.

Redis nhanh hơn Kafka cho tin nhắn nhỏ (dưới ms), nhưng thiếu sao chép và độ bền nặng của Kafka.

3.4 NATS

NATS là hệ thống siêu nhẹ viết bằng Go. Độ trễ dưới ms, pub/sub tích hợp, request/reply. NATS JetStream thêm lưu trữ và đảm bảo giao hàng đúng một lần.

3.5 ZeroMQ và nanomsg

Các thư viện không có broker cung cấp trừu tượng hóa socket cho giao tiếp peer-to-peer. ZeroMQ xử lý 5M+ tin nhắn/s và đã được thử nghiệm thực chiến từ năm 2007. nanomsg (và NNG) là "người kế nhiệm" với độ trễ tốt hơn trên tin nhắn nhỏ (<64KB).

4. PUB/SUB Thời Gian Thực cho Client: Centrifugo

Centrifugo là máy chủ PUB/SUB tự lưu trữ viết bằng Go, được tối ưu hóa để broadcast đến hàng nghìn/triệu client qua WebSocket, SSE hoặc gRPC.

Tại sao Centrifugo cho Giao Dịch Thuật Toán:

• Xử lý 1M kết nối WebSocket và 30M tin nhắn/phút trên một máy chủ.
• Hỗ trợ streaming 60Hz.
• Nén delta (thuật toán Fossil) để giảm thiểu lưu lượng.
• Hoàn hảo cho "dặm cuối" đến web dashboard hoặc ứng dụng di động.

5. Kho Lưu Trữ Dữ Liệu Truy Cập Thời Gian Thực

5.1 QuestDB — Time-Series cho Giao Dịch

QuestDB là cơ sở dữ liệu time-series nguồn mở viết bằng Java (zero-GC), C++ và Rust.

• Truy vấn: Thực thi vector hóa dưới ms qua SIMD.
• SAMPLE BY/ASOF JOIN: Tiện ích mở rộng SQL thân thiện với trader gốc.
• WAL: Append độ trễ cực thấp.
• Được sử dụng bởi B3 (sàn giao dịch chứng khoán Brazil).

5.2 Redis như Tầng Dữ Liệu

Thường là tầng trung gian:

• Cache nóng cho truy cập giá O(1).
• Sorted set cho orderbook.
• Script Lua cho hoạt động nguyên tử.

5.3 Giải Pháp Chuyên Biệt: RayforceDB, AXL DB

Cơ sở dữ liệu vector dựa trên C tối giản (nhị phân <1MB) không có phụ thuộc và tăng tốc SIMD. Tập trung vào độ trễ xác định cho HFT.

6. Tuần Tự Hóa: Protobuf vs SBE vs JSON

7. Kiến Trúc Tham Khảo

7.1 Arbitrage Crypto (Tần Suất Trung Bình)

Sàn giao dịch → Collector (Rust) → Redis (Hot) → Strategy (Python) → gRPC → Router (Rust) → Sàn giao dịch.

7.2 HFT Market Making (Co-location)

Exchange Feed → Kernel Bypass NIC → Aeron IPC → Strategy (C++) → SBE → Aeron → Sàn giao dịch.

8. Lời Khuyên Thực Tế

• <10 μs (HFT): FPGA, bộ nhớ chia sẻ, SBE, Aeron IPC.
• 10–100 μs: Aeron (UDP), gRPC+UDS, ZeroMQ.
• 100 μs – 1 ms: gRPC (TCP), WebSocket, Protobuf.
• 1–10 ms (Tần Suất Trung Bình): WebSocket, Kafka, Redis.
• >10 ms (Tần Suất Thấp / Swing): REST API là đủ. DCA, tái cân bằng, quản lý danh mục đầu tư.

Đừng tối ưu hóa những gì không phải là bottleneck. Nếu chiến lược của bạn mất 50 ms để quyết định, khoản tiết kiệm 100 μs của Aeron sẽ không quan trọng. Kiến trúc hybrid là bình thường: dùng REST để thiết lập, gRPC cho trung tâm, và WS để phân phối.

Kho Benchmark

Các con số độ trễ được trích dẫn trong bài viết này có thể tái tạo với suenot/trading-ipc-bench — một bộ benchmark Python nguồn mở bao gồm tất cả các IPC transport chính được thảo luận ở đây: TCP, UDS, Named Pipe, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub và Shared Memory.

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

Chạy trên phần cứng của bạn — kết quả sẽ khác với các con số trong bài viết này tùy thuộc vào CPU, OS, phiên bản kernel và cấu hình của bạn. Đó là điểm mấu chốt.

Kết Luận

Không có công nghệ truyền thông "hoàn hảo". Mỗi cấp độ có yêu cầu riêng: bên ngoài (khả năng tương thích), nội bộ (độ trễ), pipeline (độ tin cậy) và client (linh hoạt). Kiến trúc là về việc chọn đúng công cụ cho công việc cụ thể.