在分散式系統中，處理金錢交易的帳本系統（Ledger System）最核心的要求就是正確性。Uber 採用的是複式簿記（Double-entry accounting）模型，這是一種金融標準，要求每一筆資金移動都必須有對應的借方與貸方紀錄，以確保資金流向可追溯且總額平衡。
然而，這種模型在實作時面臨一個巨大的技術挑戰：強一致性（Strong Consistency）。為了確保餘額計算正確，針對單一帳戶的更新必須經過嚴格外的序列化處理，也就是說，同一時間只能有一個交易在修改該帳戶的狀態。
當系統遇到熱點帳戶（Hot Account）時，問題就來了。所謂熱點帳戶，是指在短時間內有大量更新湧入的單一帳戶，例如大規模的對帳調整、系統性補償或營運修正。在舊有的處理模式下，每一筆更新請求都會觸發一次完整的生命週期：讀取當前狀態、驗證權限與餘額、計算新餘額、寫入新分錄並記錄審計日誌。
對於 Junior 工程師來說，可以將其想像成每買一件商品就要跑一次完整的結帳流程（開單、刷卡、列印收據、存檔）。如果一個帳戶每秒有 30 筆交易，系統就必須進行 30 次讀寫循環。這會導致嚴重的儲存壓力（Storage Overhead）與寫入放大（Write Amplification），最終造成系統瓶頸，甚至讓原本應該在幾分鐘內完成的對帳工作拖延數小時。
為了突破這個瓶頸，Uber 引入了基於批次（Batching）的執行模型。其核心邏輯是將原本單筆處理的模式，轉變為在極短的時間視窗內，將針對同一帳戶的所有操作進行聚合。
這個新架構將處理流程分為三個階段。首先是分組階段，系統根據帳戶親和性（Account Affinity）將進入的更新請求在約 250 毫秒的時間窗內進行分組。接著是原子執行階段，系統不再為每筆交易讀寫一次資料庫，而是將整個批次視為一個原子單位，一次性讀取狀態、執行所有驗證與餘額計算，最後一次性寫入結果。最後則是傳播階段，將結果同步至審計日誌與下游的對帳管線。
在技術實作上，Uber 使用了 Redis 來協調分組邏輯，並採用樂觀原子更新（Optimistic Atomic Updates）機制。樂觀鎖的意思是系統假設衝突不會頻繁發生，在寫入時才檢查版本號是否被更改，若被更改則重新嘗試。這種做法避免了長時間持有資料庫鎖定，從而實現水平擴展（Horizontal Scalability）。
在設計這種系統時，工程師必須在批次視窗大小（Batch Window Size）與端到端延遲（End-to-End Latency）之間做權衡。如果視窗設得太大，雖然吞吐量會更高，但使用者感知的延遲會增加；如果視窗太小，則無法有效降低儲存壓力。Uber 最終選擇 250 毫秒作為平衡點，既能維持近乎即時的處理速度，又能將單一帳戶的吞吐量提升至每秒 30 次以上。
此外，為了防止單一批次中的某筆錯誤交易導致整個批次失敗，Uber 實作了故障隔離機制（Failure Isolation）。這確保了暫時性的網路或儲存問題能被限制在單筆操作層級，避免因重複嘗試整個批次而造成系統負荷進一步加劇。
透過這次架構演進，Uber 成功將原本需要數小時才能跑完的財務管線縮短至數分鐘，在不犧牲金融級一致性的前提下，極大地提升了系統的營運韌性。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。