熱點賬戶解決方案

在某一瞬間，單個賬戶集中的發生資金變動，若不加控制，其賬戶餘額會因發生髒讀、覆蓋更新等情況而錯誤記錄。如果簡單的以悲觀鎖、樂觀鎖的方式限制，雖然不會發生資料錯誤，但會造成服務不可用（該賬戶的更新請求全部失敗）。而請求重試、再次網路通訊的開銷並不能忽略不計。

在賬戶系統的實際業務中，發生「熱點賬戶」情況的一般有兩種：

區域性熱點賬戶

還款時一人 -> 多人

放款時多人 -> 一人

債轉時多人 -> 一人（基於業務系統的特定場景設定，此處認為債權轉出人為熱點賬戶）

區域性熱點賬戶可通過分布式鎖的方式處理，本文不再贅述。

全域性熱點賬戶

平台支出賬戶、平台收入賬戶、過渡賬戶。。這些賬戶總是在發生資金變動

既然是普適的解決方案，那就考慮該賬戶會大量併發的發生餘額增加、餘額減少、餘額凍結、餘額解凍的操作，其中餘額凍結和餘額解凍可視同為增、減，簡化模型，下面以hot賬戶為例

1.收到請求 -> 2.落庫待處理，返回處理中 -> 3.落庫資料批量彙總處理，狀態控制 -> 4.返回處理結果(取決於第2步)

第2步可根據實際業務，返回成功(例如業務上餘額無限大的賬戶或者允許為負值的賬戶)

h賬戶初始資金為0，幾乎同時收到請求：h賬戶放款給a賬戶100，放款給b賬戶100，c賬戶還款給h賬戶50，d賬戶還款給h賬戶250

資料按順序落庫後，跑批任務彙總處理，假設每次處理3條

第乙個批次經過計算，發現餘額不足，於是將(3)餘額增加的操作先執行，並更新狀態，(1)、(2)不執行也不更新

第二個批次經過計算，餘額充足，執行所有操作並更新狀態

雖然凍結相當於減，解凍相當於增，但是凍結得優先於解凍執行，所以最終得出了如下執行順序：

增->凍結->解凍->減

首先我要問，什麼場景下我們需要得到實時餘額？

判斷錢夠不夠扣，夠不夠凍結？

no no no，我們要求熱點賬戶的資金處理都必須非同步，這意味著請求發過來只會得到處理中，成功與否我們會通知你。而且就是你查詢的時候錢充足，並不意味著發生變動的時候也充足，這類查詢是沒有意義的。要麼像zf這類錢永遠充足的賬戶，查詢就更沒有意義了

財務、審計。。whatever需要統計資料？

這個可以有，我們將賬戶餘額和緩衝記錄表內的資料實時計算告訴你。但是不要說我實時計算的餘額不准，因為會有未提交的事務balabala。。那麼親，這和熱點賬戶沒關係，即使你查詢乙個非常普通的賬戶，碰巧該賬戶同時在更新，你也查不准。。實時計算的餘額在那一瞬間是準確的，而且我認為這類需求不會很大

只增不減、只減不增的賬戶，上述的框架是可以包含解決的，也沒必要特殊優化

資金永遠充足的賬戶，在流程的第2步，可以落庫後返回成功

如果h->a的劃賬要求兩個賬戶事務一致性，那麼就需要對我們流程第2步中的表做修改了，將h->a整個落庫，後批量處理