การสื่อสารข้อมูลในระบบ Algo Trading: ภาพรวมเทคโนโลยี

ในการซื้อขายแบบอัลกอริทึม ความแตกต่างระหว่างกำไรและขาดทุนอาจวัดได้ในระดับไมโครวินาที สถาปัตยกรรมการส่งข้อมูลเป็นหนึ่งในปัจจัยสำคัญที่กำหนดประสิทธิภาพของระบบการซื้อขาย ในบทความนี้ เราจะอธิบายเทคโนโลยีการสื่อสารในทุกระดับ: ตั้งแต่การโต้ตอบกับตลาดหลักทรัพย์ ไปจนถึงการสื่อสารระหว่างบริการภายใน การจัดเก็บ และการกระจายข้อมูล

บทความนี้จัดเรียงตามระดับ ตั้งแต่ "ภายนอก" (โปรโตคอลตลาดหลักทรัพย์) ไปจนถึง "ภายใน" (IPC, Message Broker, Storage) สะท้อนสถาปัตยกรรมจริงของแพลตฟอร์มการซื้อขายแบบอัลกอริทึม

1. การโต้ตอบกับตลาดหลักทรัพย์: REST, WebSocket, FIX

1.1 REST API

REST เป็นวิธีที่ง่ายและพบบ่อยที่สุดในการโต้ตอบกับ API ของตลาดหลักทรัพย์ แต่ละคำขอคือการเชื่อมต่อ HTTP แยกต่างหาก: TCP handshake → TLS handshake → ส่งคำขอ → รับการตอบสนอง → ปิดการเชื่อมต่อ

ปัญหาของ REST สำหรับการซื้อขาย:

แต่ละคำขอมีต้นทุนการตั้งค่าการเชื่อมต่อ แม้จะใช้ HTTP keep-alive โมเดล "request-response" ทำให้ไม่สามารถรับข้อมูลได้เร็วกว่าการส่งคำขอ ซึ่งนำไปสู่การ polling ซึ่งเป็นวงจรไม่สิ้นสุดของคำถาม "มีข้อมูลใหม่ไหม?" ที่สร้างภาระสูงถึง 80% บนเซิร์ฟเวอร์ของตลาดหลักทรัพย์ (ตามที่นักพัฒนาตลาดหลักทรัพย์คริปโตระบุ) ตลาดหลักทรัพย์กำหนด rate limits (โดยทั่วไป 10–1,200 คำขอต่อนาที) ทำให้ REST ไม่เหมาะสมสำหรับกลยุทธ์ความถี่สูง

เมื่อไหร่ที่ REST เหมาะสม: การดึงข้อมูลประวัติ (candles, OHLCV), การจัดการบัญชี (ยอดดุล, ตำแหน่ง), การดำเนินการที่ไม่ต้องการข้อมูลเรียลไทม์ (DCA bots, การปรับสมดุลรายชั่วโมง)

1.2 WebSocket

WebSocket สร้างการเชื่อมต่อ TCP แบบถาวรหนึ่งครั้งซึ่งข้อมูลไหลสองทิศทาง เริ่มต้นเป็นคำขอ HTTP ปกติพร้อม header Upgrade จากนั้นเปลี่ยนไปใช้โปรโตคอล framing แบบสองทิศทาง (payload อาจเป็น JSON ข้อความหรือ binary)

ข้อดีสำหรับการซื้อขาย:

ข้อได้เปรียบหลักคือไม่มีต้นทุนต่อคำขอ เมื่อสร้างการเชื่อมต่อแล้ว ข้อมูลจะถูก push ทันทีโดยเซิร์ฟเวอร์ ความหน่วงในการส่งข้อมูลตลาดผ่าน WebSocket โดยทั่วไปน้อยกว่า 50 ms จาก gateway ของตลาดหลักทรัพย์ไปยังไคลเอนต์ คุณสามารถสมัครสมาชิก 50+ สัญลักษณ์พร้อมกันผ่านการเชื่อมต่อเดียว

จุดสำคัญ: คำสั่งซื้อผ่าน WebSocket นักเทรดจำนวนมากไม่รู้ว่าบางตลาดหลักทรัพย์ (Binance, HitBTC, Deribit, Bybit เป็นต้น) อนุญาตให้ส่งคำสั่งซื้อผ่าน WebSocket ไม่ใช่แค่รับข้อมูล ซึ่งเร็วกว่า REST โดยพื้นฐาน เพราะ:

• ไม่มี TCP/TLS handshake สำหรับแต่ละคำสั่งซื้อ (การเชื่อมต่อ "อุ่น" แล้ว)
• ไม่มีต้นทุน HTTP (headers, cookies เป็นต้น)
• โมเดล asynchronous: คุณส่งคำสั่งซื้อและรับการยืนยันผ่าน WebSocket เดิมโดยไม่บล็อก thread

ตาม Deribit, WebSocket และ FIX มักมีความเร็วในการดำเนินการเหมือนกัน REST ช้ากว่าเล็กน้อยเนื่องจากการประมวลผลล่วงหน้าที่ระดับการเชื่อมต่อ คำสั่งซื้อผ่าน WebSocket เข้าสู่คิว matching engine เช่นเดียวกับคำสั่ง FIX

ปัญหาการผสม Context หากคุณส่งคำสั่งซื้อผ่าน REST แต่รับการแจ้งเตือนการดำเนินการผ่าน WebSocket จะเกิด race condition: การแจ้งเตือน WebSocket อาจมาถึงก่อนที่คำขอ REST จะเสร็จสิ้น ซึ่งนำไปสู่ความไม่สอดคล้องของสถานะ วิธีแก้ไขคือส่งคำสั่งซื้อผ่าน WebSocket เดียวกัน ย้ายไปสู่โมเดล asynchronous อย่างสมบูรณ์

1.3 โปรโตคอล FIX (Financial Information eXchange)

FIX คือมาตรฐานอุตสาหกรรมสำหรับการซื้อขายอิเล็กทรอนิกส์ มีมาตั้งแต่ปี 1992 (สร้างโดย Fidelity Investments และ Salomon Brothers) เป็นโปรโตคอล binary-over-TCP ที่ออกแบบมาเฉพาะสำหรับการซื้อขาย

สถาปัตยกรรม FIX:

• Session layer — จัดการการเชื่อมต่อ, heartbeats, การกำหนดลำดับ, การกู้คืน gap รับประกันการส่งและลำดับข้อความ
• Application layer — ตรรกะทางธุรกิจ: ประเภทคำสั่งซื้อ, รายงานการดำเนินการ, คำขอข้อมูลตลาด

ข้อความ FIX ประกอบด้วยคู่ "tag=value" คั่นด้วยอักขระ 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 เป็นโปรโตคอล TCP แบบ native โดยไม่มีชั้น HTTP AWS ในคู่มือการปรับแต่ง tick-to-trade สำหรับตลาดหลักทรัพย์คริปโต แนะนำ FIX อย่างชัดเจนแทน REST และ WebSocket เพื่อลดความหน่วงที่เกิดจากโปรโตคอล FIX ทำงานในระดับไมโครวินาที ในขณะที่ WebSocket อยู่ในระดับมิลลิวินาทีโดยทั่วไป

ที่ที่ FIX ครองอำนาจ: DMA (Direct Market Access) ไปยัง matching engine ของตลาดหลักทรัพย์, การซื้อขายแบบอัลกอริทึมและ HFT ในสถาบัน, การรวม liquidity (prime brokers เชื่อมต่อกับธนาคารหลายสิบแห่งผ่าน FIX)

ข้อจำกัดของ FIX: ความซับซ้อนของการรวมระบบ, รูปแบบข้อความที่ล้าสมัย (tag-values แบบข้อความมีประสิทธิภาพน้อยกว่ารูปแบบ binary), ความยากในการเริ่มต้น ในอุตสาหกรรมคริปโต FIX รองรับโดยตลาดหลักทรัพย์จำนวนจำกัด

1.4 SBE (Simple Binary Encoding) — FIX เวอร์ชันวิวัฒนาการ

SBE คือรูปแบบการ serialization แบบ binary ที่สร้างโดย High Performance Working Group ภายใน FIX Trading Community ภารกิจคือการแทนที่รูปแบบ FIX แบบข้อความด้วยการแสดงผล binary แบบกะทัดรัดสำหรับการซื้อขาย ultra-low-latency

หลักการสำคัญของ SBE:

• Zero-copy flyweight pattern — encoders และ decoders ทำหน้าที่เป็น "templates" เหนือ buffer ค่าถูกเขียนโดยตรงโดยไม่มีการคัดลอกระหว่างกลาง (ต่างจาก Protobuf ที่ต้องการหลายครั้ง)
• Wire format = memory format — ข้อมูลบน wire มีลักษณะเหมือนในหน่วยความจำ ลดต้นทุนการแปลงให้น้อยที่สุด
• Fixed fields first, variable fields last — ข้อจำกัดการออกแบบที่ให้ประสิทธิภาพสูงกว่า Protocol Buffers หลายเท่า

SBE + Aeron คือการผสมผสานมาตรฐานสำหรับระบบการซื้อขายประสิทธิภาพสูง Aeron เป็นระบบส่งข้อความ open-source จาก Real Logic (สร้างโดย Martin Thompson อดีต CTO ของ LMAX Exchange และ Todd Montgomery อดีต CTO ของ 29West/Ultra Messaging) โดยพื้นฐานแล้วเป็นชั้น transport เฉพาะทางสำหรับระบบการเงินที่ทำงานผ่าน UDP และ shared memory พร้อมความหน่วงในระดับหลักไมโครวินาที SBE จัดการ serialization ในขณะที่ Aeron จัดการการส่งด้วยความล่าช้าระดับไมโครวินาที รายละเอียดเพิ่มเติมเกี่ยวกับ Aeron ในหัวข้อ 3.1

1.5 ตารางเปรียบเทียบโปรโตคอลตลาดหลักทรัพย์

2. การสื่อสารระหว่าง Microservice ภายใน

เมื่อข้อมูลเข้าสู่ระบบของคุณจากตลาดหลักทรัพย์ การประมวลผลภายในจะเริ่มต้น: การแยกวิเคราะห์ → กลยุทธ์ → การตัดสินใจ → การส่งคำสั่งซื้อ ในแต่ละขั้นตอนมีการสื่อสารระหว่างบริการ

2.1 gRPC Bidirectional Streaming (TCP)

gRPC คือ framework ของ Google ที่ใช้ HTTP/2 โดยใช้ Protocol Buffers สำหรับ serialization สำหรับการซื้อขายแบบอัลกอริทึม bidirectional streaming มีความสำคัญเป็นพิเศษ เมื่อไคลเอนต์และเซิร์ฟเวอร์ส่งสตรีมข้อความพร้อมกันผ่านการเชื่อมต่อเดียว

ทำไม gRPC เหมาะกับระบบการซื้อขาย:

• Protobuf กะทัดรัด (เล็กกว่า JSON 3–10 เท่า)
• HTTP/2 multiplexing — สตรีมหลายรายการผ่านการเชื่อมต่อ TCP เดียว
• การพิมพ์อย่างเข้มงวดผ่าน .proto schemas ที่ตรวจจับข้อผิดพลาดในเวลา compile
• การสร้างโค้ดสำหรับ Python, Rust, Go, C++, Java เป็นต้น
• Bidirectional streaming เปิดใช้งานรูปแบบ "ข้อมูลตลาดลงมา, คำสั่งขึ้นไป" ผ่านช่องทางเดียว

ตาม SmartDev, 70% ของสถาบันการเงินที่ใช้ AI-driven HFT ใช้ gRPC หรือ raw TCP สำหรับเวลาตอบสนองระดับไมโครวินาที

ตัวอย่างสถาปัตยกรรม: Market Data Collector (Rust) → gRPC stream → Strategy Engine (Python/Rust) → gRPC call → Order Router (Rust) → WebSocket/FIX → ตลาดหลักทรัพย์

2.2 gRPC ผ่าน Unix Domain Socket (UDS)

หากบริการทำงานบนเครื่องเดียวกัน (ทั่วไปสำหรับ co-location), TCP เป็นต้นทุนที่ไม่จำเป็น Unix Domain Socket (UDS) ข้ามชั้น network stack ทั้งหมด: ไม่มี TCP handshake, ไม่มี routing, ไม่มีการตรวจสอบ checksum

Benchmarks แสดงความแตกต่างที่มีนัยสำคัญ:

• gRPC ผ่าน UDS: ~102 μs/คำขอ (100K คำขอ)
• gRPC ผ่าน TCP: ~127 μs/คำขอ (100K คำขอ)
• ข้อได้เปรียบของ UDS: ~20% สำหรับข้อความเล็ก, สูงถึง 50% สำหรับข้อความใหญ่ (100KB+)

ตาม F. Werner (MPI Heidelberg) เปรียบเทียบ gRPC UDS กับ raw blocking I/O ผ่าน UDS, gRPC เพิ่มต้นทุนประมาณ 10 เท่า — ค่ามัธยฐาน ~130 μs เทียบกับ ~13 μs สำหรับ raw UDS นี่คือต้นทุนของ abstraction (HTTP/2 framing, protobuf serialization)

เมื่อไหร่ควรใช้ gRPC+UDS: การสื่อสารระหว่างกระบวนการบนเซิร์ฟเวอร์เดียวเมื่อให้คุณค่ากับความสะดวกของนักพัฒนา (schema, codegen) มากกว่าความหน่วงขั้นต่ำสุด UDS ยังให้ข้อได้เปรียบด้านความปลอดภัยผ่านสิทธิ์ไฟล์ Unix

เมื่อไหร่ไม่ควรใช้: หากคุณต้องการความหน่วง <10 μs, shared memory หรือ raw UDS โดยไม่มี gRPC ดีกว่า สำหรับอ้างอิง: raw UDS ค่ามัธยฐาน ~13 μs, gRPC UDS ค่ามัธยฐาน ~130 μs Shared memory (Aeron IPC) อยู่ต่ำกว่า 1 μs, LMAX Disruptor ring buffer อยู่ที่ประมาณ 50–100 ns ดังนั้น gRPC+UDS ช้ากว่า raw UDS ~10 เท่า และช้ากว่า shared memory 100–1,000 เท่า แต่แต่ละขั้นตอนที่ลงความหน่วงคือขั้นตอนที่ขึ้นความซับซ้อนของโค้ด

ทดลองด้วยตัวเอง: ตัวเลขความหน่วง IPC ทั้งหมดในส่วนนี้สามารถทำซ้ำได้ด้วย suenot/trading-ipc-bench ซึ่งเป็น benchmark open-source สำหรับ Python ที่ครอบคลุมการนำไปใช้: TCP, UDS, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub, Shared Memory และ Named Pipe round-trips โดยวัด p50/p95/p99/p99.9 latency และ throughput บนฮาร์ดแวร์ของคุณ

Raw UDS โดยไม่มี gRPC — หากต้นทุน gRPC มากเกินไป ให้ลบออกและเก็บแค่ socket ตัวเลือกตามลำดับประสิทธิภาพที่ลดลง:

• AF_UNIX sockets + custom serialization (SBE, FlatBuffers, MessagePack) — ~13 μs ค่ามัธยฐาน, ควบคุมสูงสุด, ความซับซ้อนสูงสุด
• ZeroMQ IPC (ipc://) — ~50–100 μs, รูปแบบสำเร็จรูป (PUB/SUB, REQ/REP) โดยไม่มีโค้ดซ้ำ, ใช้ UDS ภายใต้
• nanomsg/NNG IPC — คล้ายกับ ZeroMQ, ความหน่วงดีกว่าเล็กน้อยสำหรับข้อความเล็ก (<64 KB)
• Cap'n Proto RPC over UDS — zero-copy serialization + RPC abstraction, เร็วกว่า gRPC, มี schema

2.3 Shared Memory IPC

สำหรับ ultra-low-latency บน host เดียวกัน ให้ใช้ shared memory สองกระบวนการ map RAM segment เดียวกัน และข้อมูลผ่านโดยไม่มี syscalls (ยกเว้นการตั้งค่าเริ่มต้น)

รูปแบบ LMAX Disruptor (ring buffer ใน shared memory) จัดการ ~6 ล้าน events ต่อวินาทีบน thread เดียว แนวทางนี้เป็นหัวใจของ LMAX Exchange และระบบ HFT จำนวนมาก

การนำไปใช้: Aeron IPC (Java/C++), Chronicle Queue (Java), โซลูชันที่กำหนดเองบน mmap (Rust/C++) IronSBE (การนำ Rust SBE ไปใช้) รองรับ shared memory IPC พร้อมความหน่วง ~20 ns ที่ระดับ SPSC channel

3. ระบบ Transport: Message Broker และ Library

3.1 Aeron — มาตรฐานทอง

Aeron คือระบบ transport ข้อความประสิทธิภาพสูง open-source ที่พัฒนาโดย Real Logic ผู้สร้างคือ Martin Thompson (อดีต CTO ของ LMAX) และ Todd Montgomery (อดีต CTO ของ 29West) เริ่มต้นในปี 2014 สำหรับตลาดหลักทรัพย์หลักของสหรัฐ และปัจจุบันมีผู้มีส่วนร่วม 70+ คน และสมาชิก GitHub 5,000+ คน

ในทางปฏิบัติ: Aeron ไม่ใช่ broker (เช่น Kafka) และไม่ใช่ library socket (เช่น ZeroMQ) มันเป็นชั้น transport ที่ออกแบบมาสำหรับความหน่วงต่ำที่คาดเดาได้ ทำงานผ่าน UDP (เครือข่าย) และ shared memory (IPC) โดยให้การส่งที่เชื่อถือได้, การเรียงลำดับ, และการควบคุมการไหล ซึ่งสิ่งที่ raw UDP ขาดไป คิดว่า Aeron คือ "TCP ที่มีความหน่วงของ UDP"

คุณลักษณะของ Aeron:

• ความหน่วง: <100 μs บน cloud, <18 μs บน bare metal
• Throughput: >1M ข้อความ/วินาที ที่ความหน่วงระดับไมโครวินาที
• สูงสุด 20M+ ข้อความ/วินาที
• Brokerless — ไม่มีจุดล้มเหลวเดียว
• รองรับ unicast, multicast, และ IPC
• การควบคุมการไหลและการตรวจจับการสูญหายในตัว

Aeron Cluster — การ replication state machine แบบทนทานต่อข้อผิดพลาด (Raft consensus) สำหรับตรรกะการซื้อขายที่สอดคล้องกันพร้อมความหน่วงเพิ่มเติมน้อยที่สุด

Aeron Archive — การคงอยู่ของข้อความที่ความเร็วสตรีมเต็มพร้อมความสามารถในการ replay

Aeron Sequencer — ส่วนประกอบใหม่ล่าสุดของ ecosystem ออกแบบมาเพื่อประสานงานหลายโปรเจกต์ในองค์กรขนาดใหญ่ สร้างบน Aeron Transport และ Aeron Cluster คุณลักษณะสำคัญ:

• Distributed log — ลำดับข้อความยาวที่ replicated บนหลายเครื่องเพื่อความทนทานต่อข้อผิดพลาด
• Multiple readers — แอปพลิเคชันหลายรายการอ่านจาก log เดียวกันพร้อมกันเพื่อวัตถุประสงค์ที่แตกต่างกัน
• Decoupled teams — ทีมยังคงเป็นอิสระในขณะที่ดำเนินการภายในระบบที่ประสานงานกันเดียว
• กรณีการใช้งานเป้าหมาย: การประมวลผลข้อมูลตลาด, แพลตฟอร์ม broker, เครื่องยนต์ตลาดหลักทรัพย์

การเปรียบเทียบกับ Kafka: ทั้งคู่ใช้ distributed log แต่ Aeron สำหรับความหน่วงระดับไมโครวินาที ในขณะที่ Kafka สำหรับความทนทานและ throughput ระดับมิลลิวินาที Aeron มีอยู่สำหรับตรรกะ real-time; Kafka สำหรับ data pipelines และการวิเคราะห์

3.2 Apache Kafka

Apache Kafka คือมาตรฐานที่แท้จริงสำหรับ event streaming ในระดับขนาดใหญ่ ไม่ได้สำหรับ hot path การซื้อขาย (ความล่าช้าระดับมิลลิวินาที) แต่ขาดไม่ได้สำหรับ:

• การรวม market data: รวบรวมสตรีมจาก 100+ ตลาดหลักทรัพย์ไปยัง pipeline เดียว
• Event sourcing: บันทึกทุกการดำเนินการของระบบเป็น event topic
• CDC (Change Data Capture): สตรีมการเปลี่ยนแปลง DB การซื้อขายไปยังการวิเคราะห์
• QuestDB Integration: Kafka → QuestDB สำหรับการวิเคราะห์ tick แบบ real-time

ความหน่วงคือ 2–15 ms end-to-end ไม่เหมาะสำหรับ HFT แต่เหมาะสำหรับกลยุทธ์ที่มีขอบเขต >1 วินาที

3.3 Redis Pub/Sub และ Streams

Redis คือ in-memory store ที่ทำงานเป็น lightweight broker ด้วย

Redis Pub/Sub — fire-and-forget; ความหน่วงต่ำกว่ามิลลิวินาที เหมาะอย่างยิ่งสำหรับการแจ้งเตือน real-time: อัปเดตราคา, สัญญาณกลยุทธ์, การเตือน

Redis Streams — เพิ่มการคงอยู่และ consumer groups (mini-Kafka) รองรับการอ่านประวัติและ ACKs

Redis เร็วกว่า Kafka สำหรับข้อความเล็ก (sub-ms) แต่ขาด replication หนักและความทนทานของ Kafka

3.4 NATS

NATS คือระบบ ultra-lightweight ใน Go ความหน่วง Sub-ms, pub/sub ในตัว, request/reply NATS JetStream เพิ่มการคงอยู่และการส่งแบบ exactly-once

3.5 ZeroMQ และ nanomsg

Library brokerless ที่ให้ abstraction socket สำหรับการสื่อสาร peer-to-peer ZeroMQ จัดการ 5M+ ข้อความ/วินาที และผ่านการทดสอบในสนามรบมาตั้งแต่ปี 2007 nanomsg (และ NNG) คือ "ผู้สืบทอด" ที่มีความหน่วงดีกว่าสำหรับข้อความเล็ก (<64KB)

4. PUB/SUB แบบ Real-time สำหรับไคลเอนต์: Centrifugo

Centrifugo คือ PUB/SUB server ที่โฮสต์เองใน Go ที่ปรับแต่งสำหรับการกระจายไปยังไคลเอนต์หลายพันถึงล้านผ่าน WebSocket, SSE, หรือ gRPC

ทำไม Centrifugo สำหรับ Algo Trading:

• จัดการการเชื่อมต่อ WebSocket 1M และ 30M ข้อความ/นาทีบนเซิร์ฟเวอร์เดียว
• รองรับการสตรีม 60Hz
• Delta compression (Fossil algorithm) เพื่อลด traffic ให้น้อยที่สุด
• เหมาะอย่างยิ่งสำหรับ "ไมล์สุดท้าย" ไปยัง web dashboards หรือแอปมือถือ

5. Data Store สำหรับการเข้าถึง Real-time

5.1 QuestDB — Time-Series สำหรับการซื้อขาย

QuestDB คือฐานข้อมูล time-series open-source ที่เขียนใน Java (zero-GC), C++, และ Rust

• Queries: การดำเนินการ vectorized แบบ Sub-ms ผ่าน SIMD
• SAMPLE BY/ASOF JOIN: ส่วนขยาย SQL ที่เป็นมิตรกับนักเทรด native
• WAL: Ultra-low-latency append
• ใช้โดย B3 (ตลาดหลักทรัพย์ของบราซิล)

5.2 Redis เป็นชั้นข้อมูล

โดยทั่วไปเป็นชั้นกลาง:

• Hot cache สำหรับการเข้าถึงราคา O(1)
• Sorted sets สำหรับ orderbooks
• Lua scripts สำหรับการดำเนินการแบบ atomic

5.3 โซลูชันเฉพาะทาง: RayforceDB, AXL DB

ฐานข้อมูล vector แบบ minimalist ที่ใช้ C (binary <1MB) พร้อมการพึ่งพาเป็นศูนย์และการเร่งความเร็ว SIMD มุ่งเน้นที่ความหน่วงที่กำหนดได้สำหรับ HFT

6. Serialization: Protobuf vs SBE vs JSON

7. สถาปัตยกรรม Reference

7.1 Crypto Arbitrage (ความถี่ปานกลาง)

Exchanges → Collector (Rust) → Redis (Hot) → Strategy (Python) → gRPC → Router (Rust) → Exchange.

7.2 HFT Market Making (Co-location)

Exchange Feed → Kernel Bypass NIC → Aeron IPC → Strategy (C++) → SBE → Aeron → Exchange.

8. คำแนะนำเชิงปฏิบัติ

• <10 μs (HFT): FPGA, shared memory, SBE, Aeron IPC
• 10–100 μs: Aeron (UDP), gRPC+UDS, ZeroMQ
• 100 μs – 1 ms: gRPC (TCP), WebSocket, Protobuf
• 1–10 ms (ความถี่ปานกลาง): WebSocket, Kafka, Redis
• >10 ms (ความถี่ต่ำ / Swing): REST API เพียงพอ DCA, การปรับสมดุล, การจัดการพอร์ตโฟลิโอ

อย่าปรับแต่งสิ่งที่ไม่ใช่ปัญหาคอขวด หากกลยุทธ์ของคุณใช้เวลา 50 ms ในการตัดสินใจ การประหยัด 100 μs ของ Aeron จะไม่สำคัญ สถาปัตยกรรม Hybrid เป็นเรื่องปกติ: ใช้ REST สำหรับการตั้งค่า, gRPC สำหรับหัวใจ, และ WS สำหรับการส่ง

Benchmark Repository

ตัวเลขความหน่วงที่อ้างอิงตลอดบทความนี้สามารถทำซ้ำได้ด้วย suenot/trading-ipc-bench — ชุด benchmark Python open-source ที่ครอบคลุม IPC transport หลักทั้งหมดที่กล่าวถึงที่นี่: TCP, UDS, Named Pipe, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub, และ 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

รันบนฮาร์ดแวร์ของคุณ — ผลลัพธ์จะแตกต่างจากตัวเลขในบทความนี้ขึ้นอยู่กับ CPU, OS, เวอร์ชัน kernel และการปรับแต่งของคุณ นั่นคือจุดประสงค์

สรุป

ไม่มีเทคโนโลยีการสื่อสารที่ "สมบูรณ์แบบ" แต่ละระดับมีข้อกำหนดเฉพาะ: ภายนอก (ความเข้ากันได้), ภายใน (ความหน่วง), pipeline (ความน่าเชื่อถือ), และไคลเอนต์ (ความยืดหยุ่น) สถาปัตยกรรมคือการเลือกเครื่องมือที่เหมาะสมสำหรับงานเฉพาะ