部落格最新文章
分享技術與日常生活
大型加密貨幣交易所架構實戰系列（五）：MySQL、PostgreSQL 的擴展、調校與效能優化
前言到了系列最後一篇，我們終於可以正面回答很多人最在意的問題：在幣安、OKX 類型的超大流量交易所場景裡，MySQL 與 PostgreSQL 到底該怎麼選，又該怎麼調？ 這題沒有一刀切答案，因為交易所不是只有一種資料，也不是只有一種查詢模式。 真正成熟的架構思維，通常不是先問「哪個資料庫比較強」，而是先問「哪一類資料、哪一條鏈路、哪一種一致性要求，需要什麼樣的資料庫能力」。你把問題問對，MySQL 與 PostgreSQL 的差異才會真正有意義。
大型加密貨幣交易所架構實戰系列（四）：Leader Election、高可用切換與跨服務協調
前言分區、分片與事件流解決的是吞吐量與資料一致性的一大半問題，但大型交易所真正容易出事故的地方，往往發生在故障切換與協調。例如同一個 symbol 的撮合工作不能同時有兩個節點接手，同一組清算任務不能被兩個 worker 重複執行，週期性對帳也不能在多個節點上同時跑到互相打架。 這時候你就會遇到 Leader Election、lease、heartbeat、fencing token、split brain 這些名詞。它們看起來像分散式系統課本內容，但在交易所場景裡非常務實，因為只要選主做錯，後果不是單純多跑一個 job，而可能是重複清算、重複扣款、重複對帳，甚至同一資源被雙寫。
大型加密貨幣交易所架構實戰系列（三）：Partition、Sharding 與 MySQL / PostgreSQL 擴展策略
前言當你接受了 In-Memory + Event Sourcing + MQ 這套思路之後，下一個現實問題就來了：資料量到底怎麼扛？ 幣安、OKX 類型的交易所不是只有訂單表很大而已，而是訂單、成交、資產流水、風控事件、行情快照、K 線、稽核紀錄都會一起爆炸，而且不同資料的成長速度完全不同。 這也是為什麼大型交易所一定會走向 Partition、Sharding、冷熱資料分層，以及分角色的資料模型設計。若沒有把這一層拆清楚，再好的撮合引擎都會被下游儲存拖垮。
