Documentation
Computer Science
System Design
Patterns
LMAX Architecture

LMAX Architecture

部分內容由 LLM 生成，尚未經過人工驗證。

核心概念

LMAX Architecture 是專為極致寫入吞吐量設計的金融級帳務核心架構。

解決問題： 熱點帳戶（Hot-Spot Account）的 Row Lock 瓶頸

核心模式： In-Memory State Machine

傳統架構LMAX Architecture
每筆交易鎖 DB Row記憶體中無鎖計算
併發瓶頸在 DB單執行緒極致吞吐
DB 是 Source of TruthMQ 是 Source of Truth

架構圖 

  flowchart TB
    subgraph Clients
        C1[Client 1]
        C2[Client 2]
        C3[Client N]
    end

    subgraph Input["Input Disruptor"]
        MQ[(Message Queue<br/>Source of Truth)]
    end

    subgraph Core["Business Logic Processor"]
        BLP[Single-Threaded<br/>In-Memory Engine]
        MEM[(In-Memory State)]
    end

    subgraph Output["Output Disruptor"]
        OUT[Event Publisher]
    end

    subgraph Persistence
        DB[(Database<br/>Cold Storage)]
        SAGA[Saga Monitor]
    end

    C1 & C2 & C3 --> MQ
    MQ --> BLP
    BLP <--> MEM
    BLP --> OUT
    OUT --> DB
    OUT --> SAGA

    style MQ fill:#e1f5fe
    style BLP fill:#fff3e0
    style MEM fill:#fff3e0
    style DB fill:#f3e5f5

各層職責

層級職責
Message Queue接收所有寫入請求，作為 Source of Truth
Business Logic Processor單執行緒處理所有業務邏輯，無鎖計算
In-Memory State維護完整帳務狀態，支援即時查詢
DatabaseCold Storage，非同步批次寫入
Saga Monitor監控未完成交易，處理異常情況

關鍵技術

A. 寫入卸載 (Write Offloading)

所有寫入請求先進入 Message Queue，而非直接寫 DB：

Client Request → MQ (Persist) → In-Memory Processing
  • MQ 保證訊息持久化與順序
  • 業務處理與 DB 寫入解耦

B. 無鎖記憶體計算 (Lock-Free Processing) 

  sequenceDiagram
    participant MQ
    participant BLP as Business Logic Processor
    participant MEM as In-Memory State

    MQ->>BLP: Event 1 (Account A: +100)
    BLP->>MEM: Update Balance
    MQ->>BLP: Event 2 (Account A: -50)
    BLP->>MEM: Update Balance
    MQ->>BLP: Event 3 (Account A: +200)
    BLP->>MEM: Update Balance

    Note over BLP,MEM: 單執行緒順序處理<br/>無需任何鎖
  • 單執行緒處理所有業務邏輯
  • 無 Context Switch、無 Lock Contention
  • 現代 CPU 單核心可達 100 萬+ TPS

C. 原子性批次落庫 (Atomic Batch Persistence) 

  sequenceDiagram
    participant MEM as In-Memory State
    participant OUT as Output Disruptor
    participant DB as Database

    loop Every N seconds
        MEM->>OUT: Snapshot State
        OUT->>DB: Batch Write (Atomic)
        DB-->>OUT: ACK
    end
  • 定期將記憶體狀態批次寫入 DB
  • DB 僅作為 Cold Storage / 災難復原
  • 大幅降低 DB 壓力

D. 旁路 Saga 監控 (Sidecar Reliability) 

  flowchart LR
    OUT[Output Disruptor] --> SAGA[Saga Monitor]
    SAGA --> |Timeout Detection| ALERT[Alert System]
    SAGA --> |Compensation| MQ[Message Queue]
  • 監控所有進行中的交易
  • 偵測 Timeout 或異常狀態
  • 觸發補償交易

與 Outbox Pattern 比較

維度Outbox PatternLMAX Architecture
設計目標Reliability（可靠性）Throughput（吞吐量）
資料庫角色Source of TruthCold Storage
鎖機制依賴 DB Row Lock無鎖
MQ 用途服務間溝通橋樑寫入緩衝 + Source of Truth
一致性模型Strong ConsistencyEventual Consistency
架構複雜度中高

適用場景

場景說明
加密貨幣交易所大量交易對同一帳戶（熱錢包）
支付網關高併發支付請求
電商秒殺瞬間大量庫存扣減
遊戲虛擬貨幣頻繁的金幣/點數交易

選擇建議 

  flowchart TD
    A[帳務系統設計] --> B{寫入吞吐量需求?}
    B -->|< 10K TPS| C[Outbox Pattern<br/>簡單可靠]
    B -->|> 10K TPS| D{熱點帳戶問題?}
    D -->|否| C
    D -->|是| E[LMAX Architecture<br/>極致吞吐]

何時選 Outbox Pattern

  • 寫入量中等（< 10K TPS）
  • 需要強一致性
  • 團隊熟悉傳統 DB 架構
  • 沒有明顯的熱點帳戶問題

何時選 LMAX Architecture

  • 極高寫入吞吐量需求
  • 存在熱點帳戶瓶頸
  • 可接受最終一致性
  • 有專業團隊維護複雜架構

相關主題

Global Unique IDOutbox Pattern