幣安 Ledger 如何強化您的幣安體驗
關鍵要點
幣安 Ledger 同時儲存帳戶餘額和交易，並可實現交易服務。
它創造了高流通量、24/7 全天候可用性、以及位元層級資料準確性等必要條件。
幣安 Ledger 是幣安幕後一大功臣，它是幣安最重要的技術之一。在此了解幣安 Ledger 的運作原理，以及幣安 Ledger 如何處理世界最大加密貨幣交易所的營運作業。
您是否好奇，幣安如何維持分秒高效運作？幣安每天需要處理廣大用戶群數百萬筆的交易，因此非常值得走進幣安幕後一窺究竟。
鞏固幣安技術營運的基礎，正是 Ledger。幣安 Ledger 同時儲存帳戶餘額和交易，並可實現交易服務。
幣安對於 Ledger 有高規格的需求
您可以想見，為了因應廣大用戶需要，Ledger 的規格需求相當高。我們必須考量三大要點：
高流通量，且能在尖峰時段處理大量每秒交易數 (transactions per second，TPS)。
24/7 全天候可用性，零停機時間。
位元層級的資料準確性—零資金遺失、零交易錯誤。
一起來看看一筆 Ledger 基本資料範例。以下以常見交易為例：帳戶 1 轉帳 1 BTC 至帳戶 2。
交易前餘額：
表-1
交易後餘額：
表-2
本次交易包含兩個指令：
帳戶 1 -1 BTC
帳戶 2 +1 BTC
交易執行後，將會儲存雙方的餘額記錄，以供審計與核對之用。
表-3
標準產業解決方案
標準產業帳本解決方案係以相應資料庫為準。回到前述範例，交易的兩個指令可以轉譯為兩項 SQL 敘述，並於資料庫交易中執行 (表-4)。
表-4
解決方案優勢
實行十分簡單。
可以輕鬆適用常見的資料庫微調技巧，如讀/寫分開分片處理，以改善效能。
故障轉移時，開發維運人員能夠不費力氣地復原，也能監控並維持商業資料庫運作。
解決方案缺點
如果發生資料鎖的情形，導致多個指令並行競爭，TPS 將會大幅下降。
水平擴展難以有效改善效能。
帳戶交易過熱問題
很遺憾地，對於幣安而言，上述的業界解決方案無法因應我們的高規格需求。交易發生時，必須鎖定每一項相關記錄。雖然部分帳戶處理的交易相對較少，但當然也有發生許多並行交易的活躍帳戶。在這樣的情況下，僅有一筆交易能夠鎖定帳戶交易記錄。
其他交易因而無法執行，必須等候鎖定解除。這類情形稱為「帳戶交易過熱問題」，我們的內部測試顯示，問題發生時，TPS 會下跌至少十倍。您可在表 5 進一步了解這項問題。
帳戶交易過熱範例：
表-5
幣安 Ledger 解決方案
我們如何處理帳戶交易過熱問題？
處理上述問題的可行方案之一，即是將多緒模式創新改換為單緒模式。這麼做可以避免指令並行競爭的情況，也因此免除了帳戶交易過熱問題。
全新指令緒模式
以訊息為基準進行傳輸溝通
採用全新指令緒模式後，需要解決一個傳輸問題。狀態機層為單緒作業，但是網路層是多緒作業，兩種相異作業層如何有效進行溝通呢？
解決問題的下一步便是使用 Disruptor [1]。它的設計以環形緩衝區為主，能夠創造無需鎖定的高效能佇列。
高可用性
到目前為，透過使用記憶體模式與 RocksDB [2] 本機儲存，我們已可達成高效能。但依然有一項嶄新挑戰有待解決。現在，我們需要關注資料是否具備高可用性。
為了確保節點之間的資料一致性，我們使用 Raft 共識演算法 [3]。這意味著資料備份數量等於非領導者節點的數量。演算法也會確保系統至少半數的節點健全運作，以協助提供服務高可用性。
Raft 網域的職務角色：
領導者。領導者會處理所有客戶要求，並將作業複製給所有追蹤者。
追蹤者。追蹤者會追隨領導者執行所有作業。如果領導者節點故障，將在追蹤者節點中擇一作為新領導者。
學習者。學習者是沒有投票權的追蹤者，它會將每一冪等/交易的變動記錄在其他服務內。
Raft 網域的職務角色
指令查詢職責分離 (Command Query Responsibility Segregation，CQRS)
我們亦想確保 Ledger 的關鍵條件之一，即其是否擁有更佳的寫入績效、以及更多元的查詢條件能力。為此，我們需要創造不同網域。Raft 網域基於 Raft+RocksDB，可提供更有效的寫入效能，且查看網域可接收 Raft 網域的訊息，並儲存至相關資料庫供外部查詢。我們還會在建構層面上採用指令查詢職責分離。
Ledger 架構
整體架構
Raft 和 Ledger 的條款：
表-6
查看網域職責
Raft Ledger 中心
使用學習者製造的訊息，並在 MySQL 儲存交易和餘額資料，以供查詢之用。
處理作業要求
交易要求首先會經過網路層、帳本層 (要求處理器)，然後是 Raft 層 (Raft 同步記錄)。接著要求會返回帳本層 (狀態機)、網路層 (回應處理器)，最終將回應傳回給客戶。
資料會透過佇列在兩個層之間傳輸。
網路層 ‑ 反序列化 RPC 要求，並放入要求佇列。
帳本層 ‑ 取得佇列要求，並準備作業語境。隨後要求的中繼資料會置入 Raft 佇列。
Raft 層 ‑ 自 Raft 佇列取得要求中繼資料，並與所有追蹤者同步。隨後將結果放入適用佇列。
帳本層 ‑ 自適用佇列取得資料，並更新狀態機。隨後將結果放入回應佇列。
網路層 ‑ 自回應佇列取得結果，建構並序列化回應資料，然後返回至客戶端。
處理作業要求
資料復原
所有 Ledger 節點都會根據作業期間觸發通用快照。此外，我們還會持續導入快照。每個節點都會在相同的 Raft 記錄指數觸發，以確保狀態機在各個節點觸發快照時維持相同狀態。快照隨後會上傳至 S3 由檢查者驗證，並作為冷備份使用。
Ledger 重新啟動時，它會讀取本機快照並重建狀態機。隨後重播本機 Raft 記錄，並自領導者同步最近記錄，直到最新指數都已擷取完成為止。如果本機快照或 Raft 記錄不存在，將會向領導者擷取。
快照與復原
災害容忍能力
若要改善可用性與容錯能力，Ledger 節點必須部署在不同區域。只要超過半數的節點運作健全，資料便不會遺失，故障轉移可在一秒內完成。
即使在極低的可能性之下發生整個叢集故障的狀況，我們仍可透過儲存在 Amazon S3 的持續性快照復原叢集，並透過下游系統取得最新遺失資料。
容錯能力
效能
下表顯示硬體規格的效能測試
內部測試證實，4 節點叢集 (一個領導者、兩個追蹤者、一個學習者) 可處理 10,000 TPS 以上。透過這項設計，叢集可逐一處理所有交易筆數。完全不會發生鎖定或指令競爭情況。因此，即使帳戶交易過熱，TPS 仍可維持正常情形下的高效能。
帳戶交易過熱的 TPS
以下圖表顯示每筆交易的延遲情形。大多數交易都可在 10 毫秒內完成。較慢的交易則可在 25 毫秒內完成。
延遲時間 (毫秒，ms)
幣安 Ledger 引領產業發展
有鑑於成效驚人，我們對於獨特的幣安 Ledger 解決方案深感自豪。您可以看到，產業針對帳戶交易過熱問題的傳統解決方式並不能滿足幣安與客戶的需求。但是，透過使用專為幣安基礎架構設計的方案，我們便能達成運作最為順暢的交易所與產品體驗。現在我們很高興能與您分享幣安經驗，希望您更加理解幣安服務的運作原理。
閱讀下列文章，獲得更多幣安基礎架構的技術資訊：
參考資料
[1] LMAX Disruptor
[2] RocksDB
[3] Raft 共識演算法