為什麼高頻交易選擇 C++ 而非 Go

核心原則：可預測性 > 平均效能

高頻交易的核心需求不是「平均快」，而是「穩定快」。

1. 延遲的可預測性

C++ - 可預測的延遲

auto start = high_resolution_clock::now();
send_order();  // 幾乎恆定的執行時間

Go - 不可預測的延遲

start := time.Now()
sendOrder()  // 可能被 GC 打斷

關鍵點：高頻交易中，P99 延遲比平均延遲重要 100 倍。一次 GC 造成的 10ms 延遲可能錯失整個交易機會。

2. 零 GC 要求

C++ 記憶體管理

// 完全控制記憶體
class OrderPool {
    std::array<Order, 10000> orders;  // 預分配，零動態分配
    // 自定義記憶體管理，無 GC
};

高頻交易系統要求：

零動態記憶體分配（交易時段）
預分配所有資源
確定性記憶體回收

Go 的 GC 無法完全關閉，即使調優也只能減少頻率。

3. 硬體層級控制

CPU 親和性設定

// C++ - CPU 核心綁定
cpu_set_t cpuset;
CPU_SET(core_id, &cpuset);
pthread_setaffinity_np(thread, sizeof(cpuset), &cpuset);

NUMA 優化

// 指定 NUMA 節點分配記憶體
numa_alloc_onnode(size, node);

CPU 指令優化

__builtin_prefetch(data);  // 預取快取
_mm_pause();               // CPU 等待優化

Go 無法提供這些底層硬體控制能力。

4. 內核旁路技術

用戶態網路棧

// C++ 可使用 DPDK/OpenOnload 繞過內核
dpdk_send_packet(packet);  // 直接操作網卡，延遲 < 1μs

DPDK: 完全繞過內核網路棧
OpenOnload: Solarflare 網卡的內核旁路
VMA: Mellanox 的用戶態加速

Go 的網路棧無法繞過內核，必須經過系統調用。

5. 奈秒級時間精度

硬體時間戳

// C++ - TSC (Time Stamp Counter)
inline uint64_t rdtsc() {
    unsigned int lo, hi;
    __asm__ volatile("rdtsc" : "=a" (lo), "=d" (hi));
    return ((uint64_t)hi << 32) | lo;
}

高頻交易測量延遲用奈秒，不是毫秒：

網路延遲：100-500 奈秒
處理延遲：10-100 奈秒

6. 實際延遲要求

交易類型	延遲要求	適用技術
超高頻交易	< 1 微秒	FPGA/ASIC
高頻交易	< 10 微秒	C++ + 內核旁路
低延遲交易	< 1 毫秒	C++/Rust
算法交易	< 10 毫秒	C++/Java
一般交易	< 100 毫秒	Go/Java/Python

7. 編譯期優化

模板元編程

template<typename T>
inline void process_order(T&& order) {
    // 編譯期完全內聯，零開銷抽象
}

編譯期計算

constexpr uint64_t calculate_hash() {
    // 編譯期計算，運行時零成本
}

C++ 能在編譯期進行大量優化，Go 的編譯期優化相對有限。

8. 系統級部署優化

高頻交易系統配置

# CPU 優化
- 關閉超線程 (Hyper-Threading)
- 隔離 CPU 核心 (isolcpus)
- 關閉 CPU 頻率調節
- 禁用 C-States

# 中斷優化
- IRQ 親和性設定
- 關閉不必要的中斷

# 記憶體優化
- 使用大頁 (Huge Pages)
- 記憶體鎖定 (mlock)
- NUMA 綁定

# 內核優化
- 使用實時內核 (RT-Linux)
- 調整內核參數

Go 程序無法充分利用這些系統級優化。

9. 風險與成本

延遲的商業影響

一次 GC 導致的延遲可能造成：

錯失套利機會：損失數萬至數百萬美元
滑點擴大：執行價格惡化 0.01% = 巨額損失
被其他 HFT 搶先：策略完全失效
觸發風控：超時導致訂單取消

實際案例

Knight Capital (2012): 軟體錯誤 45 分鐘損失 4.4 億美元
每微秒延遲在某些市場可能意味著每年數百萬美元差異

10. Go 的適用場景

Go 適合的金融科技應用：

API 網關

延遲要求：< 100ms
併發要求：高
Go 優勢：goroutine 處理大量連接

數據處理管道

延遲要求：秒級
吞吐量要求：高
Go 優勢：並發處理能力

監控和告警系統

延遲要求：秒級
可靠性要求：高
Go 優勢：簡單可靠

回測系統

延遲要求：無實時要求
計算要求：高
Go 優勢：開發效率高

技術選型矩陣

場景	延遲要求	建議語言	關鍵因素
HFT 核心引擎	< 10μs	C++/C/ASM	硬體控制、零 GC
市場數據處理	< 1ms	C++/Rust	低延遲、高吞吐
風控系統	< 10ms	C++/Java	穩定性、可預測
訂單管理系統	< 50ms	Java/C#	業務邏輯複雜
API 服務	< 100ms	Go/Java	高併發、開發效率
後臺系統	< 1s	Go/Python	開發速度、維護性
數據分析	分鐘級	Python/R	生態系統、函式庫

結論

Go 很快，但不夠「穩定快」

高頻交易選擇 C++ 的核心原因：

確定性延遲 > 平均延遲
硬體控制能力
零 GC 可能性
奈秒級精度
內核旁路支援

Go 在需要高吞吐量和開發效率的場景表現優異，但在需要極低且穩定延遲的高頻交易核心系統中，C++ 仍是不可替代的選擇。

記住：在高頻交易中，最慢的那 1% 請求決定了系統的成敗，而不是平均的 99%。

Keyboard shortcuts

Jason's Notes