為什麼高頻交易避開 Go？

🎯 核心原因

1. GC Stop-The-World 暫停 ⏸️

Go GC 暫停時間：50-500 微秒（甚至更久）
高頻交易要求：   < 10 微秒延遲

❌ 即使 Go 1.5+ 改進很多，仍有不可預測的暫停
❌ 在關鍵時刻暫停 = 錯失交易機會 = 虧損

問題本質：

• GC 會在不可預測的時間點觸發
• 暫停期間無法處理任何交易邏輯
• 高頻交易中，微秒級的延遲就可能導致套利機會消失

2. 延遲的可預測性 📊

高頻交易最重視的不只是「平均延遲」，更是「最壞情況延遲」。

高頻交易寧願要：

「穩定的 5 微秒」>>> 「平均 3 微秒，但偶爾 500 微秒」

為什麼？

• 長尾延遲（tail latency）會導致：
  • 錯過最佳報價
  • 被其他機器人搶先
  • 在波動市場中吃到滑點

3. 記憶體控制 🧠

C/C++/Rust/Zig 的優勢：

• ✅ 手動管理記憶體，精確控制 memory layout
• ✅ 可以使用 memory pool、arena allocator
• ✅ 避免記憶體碎片化
• ✅ Cache-friendly 數據結構（提升 CPU cache hit rate）
• ✅ 可以使用 lock-free data structures

Go 的限制：

• ❌ 自動記憶體管理，無法精確控制
• ❌ 無法完全避免 heap allocation
• ❌ GC 掃描會影響 CPU cache
• ❌ 難以優化 memory locality

實際影響：

// C++ - 完全控制記憶體
struct Order {
    uint64_t price;
    uint64_t quantity;
    uint64_t timestamp;
}; // 24 bytes, cache-line aligned

Order order_pool[10000]; // 預先分配，零 GC 開銷

// Go - 自動管理，有 GC 開銷
type Order struct {
    Price     uint64
    Quantity  uint64
    Timestamp uint64
}

orders := make([]*Order, 10000) // 會觸發 GC

🔍 各語言在 HFT 的定位

💡 Go 在交易系統的定位

❌ Go 不適合：

1. Ultra-low latency trading engine (< 10 μs)

   • 需要納秒/微秒級響應
   • 每一微秒都影響盈虧

2. 交易所 matching engine

   • 需要處理每秒百萬級訂單
   • 延遲必須極度可預測

3. 納秒級套利

   • Latency arbitrage
   • Co-location 交易

4. Market data feed handler（極端高頻）

   • 需要解析每秒百萬級 tick data
   • 零延遲容忍度

✅ Go 很適合：

1. 中頻交易（秒級、分鐘級）

   • 策略執行頻率：1-1000 次/秒
   • 延遲容忍度：> 10 毫秒

2. 風控系統

   • 實時監控倉位
   • 風險指標計算
   • 異常檢測

3. 監控與告警系統

   • 系統健康檢查
   • 性能監控
   • 日誌聚合

4. WebSocket / REST API 服務

   • 行情分發
   • 訂單路由
   • 用戶接口層

5. 策略回測與數據處理

   • 歷史數據分析
   • 策略參數優化
   • 報表生成

6. Market Maker（非 ultra-HFT）

   • 如果延遲要求 > 10 毫秒
   • 訂單頻率 < 100 筆/秒
   • 你的 adaptive market maker 很適合用 Go！

🎯 如何選擇語言？

決策樹：

是否需要 < 1 毫秒延遲？
│
├─ 是 ──> 是否需要 < 10 微秒延遲？
│         │
│         ├─ 是 ──> 選擇 C/C++/Rust
│         │         (交易所核心、ultra-HFT)
│         │
│         └─ 否 ──> 考慮 Rust/C++
│                   (一般 HFT、低延遲系統)
│
└─ 否 ──> 是否需要極高吞吐量？
          │
          ├─ 是 ──> 選擇 Go/Rust
          │         (中頻交易、API 服務)
          │
          └─ 否 ──> 選擇 Go/Python
                    (策略開發、數據分析)

量化判斷標準：

📌 實務建議

1. 混合架構（業界主流做法）

┌─────────────────────────────────────┐
│      交易系統分層架構                 │
├─────────────────────────────────────┤
│  交易引擎核心 (C++/Rust)             │ ← 微秒級延遲
│  ├─ Order matching                  │
│  ├─ Risk checks                     │
│  └─ Market data processing          │
├─────────────────────────────────────┤
│  API Gateway (Go)                   │ ← 毫秒級延遲
│  ├─ WebSocket connections           │
│  ├─ REST API                        │
│  └─ Order routing                   │
├─────────────────────────────────────┤
│  風控/監控 (Go)                      │ ← 秒級處理
│  ├─ Position monitoring             │
│  ├─ Alert system                    │
│  └─ Dashboard                       │
├─────────────────────────────────────┤
│  數據分析 (Python/Go)                │ ← 分鐘/小時級
│  ├─ Strategy backtesting            │
│  ├─ Performance analysis            │
│  └─ Reporting                       │
└─────────────────────────────────────┘

典型公司架構：

• Jane Street, Citadel, Jump Trading: 核心用 C++/OCaml，周邊用 Python/Go
• Coinbase, Binance: Matching engine 用 C++，API 用 Go
• 小型做市商: 全棧 Go（如果不做 ultra-HFT）

2. Go 的性能優化技巧

如果堅持使用 Go 進行高頻交易，可以採用以下優化：

減少 GC 壓力：

// ❌ 不好：頻繁分配
func processOrder() {
    order := &Order{...} // 每次都分配
    // ...
}

// ✅ 好：使用 sync.Pool
var orderPool = sync.Pool{
    New: func() interface{} {
        return &Order{}
    },
}

func processOrder() {
    order := orderPool.Get().(*Order)
    defer orderPool.Put(order)
    // ...
}

調整 GC 參數：

# 增加 GC 觸發閾值（減少 GC 頻率，但增加暫停時間）
GOGC=800 ./your-trading-bot

# 設置最大記憶體限制（Go 1.19+）
GOMEMLIMIT=8GiB ./your-trading-bot

避免 heap allocation：

// ❌ 不好：逃逸到 heap
func getPrice() *float64 {
    price := 100.5
    return &price // 逃逸到 heap
}

// ✅ 好：留在 stack
func getPrice() float64 {
    return 100.5
}

使用 zero-allocation 技巧：

// 使用 strings.Builder 而不是 string concatenation
var builder strings.Builder
builder.WriteString("order_")
builder.WriteString(orderID)

// 使用 slice 容量預分配
orders := make([]Order, 0, 1000)

但即使如此，仍然無法完全消除 GC 暫停！

3. 何時該從 Go 遷移到 Rust/C++？

遷移信號：

1. ✅ 延遲監控顯示 P99 > 10ms
2. ✅ GC 暫停影響交易執行
3. ✅ 交易頻率增加到 > 1000 筆/秒
4. ✅ 與其他 HFT 競爭時處於劣勢
5. ✅ 需要與交易所 co-location

遷移策略：

Phase 1: 保留 Go 做快速原型開發
         ↓
Phase 2: 將核心引擎改寫為 Rust/C++
         ├─ Order execution
         ├─ Market data handler
         └─ Risk engine
         ↓
Phase 3: Go 保留在非關鍵路徑
         ├─ Admin dashboard
         ├─ Monitoring
         └─ Logging

🏁 結論

Go 的定位：

最終建議：

if 你的系統延遲要求 < 1ms and 交易頻率 > 1000/秒:
    選擇 Rust 或 C++
    
elif 你需要快速迭代 and 團隊熟悉 Go:
    先用 Go 開發
    等系統成熟後再考慮部分模組改用 Rust
    
else:
    Go 就很好！
    專注於策略邏輯，而不是微觀優化

📚 延伸閱讀

• Why Discord is switching from Go to Rust
• Latency Numbers Every Programmer Should Know
• Go GC: Latency Problem
• High-Frequency Trading with C++

總結一句話：

Go 是絕佳的「快速開發高性能系統」的語言，但當你需要「極致性能與可預測延遲」時，C++/Rust 才是正解。選擇工具要看使用場景，沒有絕對的好壞！ 🚀