資訊專欄INFORMATION COLUMN
摘要：全局熱點賬戶平臺支出賬戶平臺收入賬戶過渡賬戶。。那么親，這和熱點賬戶沒關系，即使你查詢一個非常普通的賬戶，碰巧該賬戶同時在更新，你也查不準。。
問題描述
在某一瞬間，單個賬戶集中的發生資金變動，若不加控制，其賬戶余額會因發生臟讀、覆蓋更新等情況而錯誤記錄。如果簡單的以悲觀鎖、樂觀鎖的方式限制，雖然不會發生數據錯誤，但會造成服務不可用（該賬戶的更新請求全部失敗）。而請求重試、再次網絡通信的開銷并不能忽略不計。
在賬戶系統的實際業務中，發生“熱點賬戶”情況的一般有兩種：
局部熱點賬戶
還款時 一人 -> 多人
放款時 多人 -> 一人
債轉時 多人 -> 一人（基于業務系統的特定場景設置，此處認為債權轉出人為熱點賬戶）
局部熱點賬戶可通過分布式鎖的方式處理，本文不再贅述。
全局熱點賬戶
平臺支出賬戶、平臺收入賬戶、過渡賬戶。。這些賬戶總是在發生資金變動
前提
既然是普適的解決方案，那就考慮該賬戶會大量并發的發生余額增加、余額減少、余額凍結、余額解凍的操作，其中余額凍結和余額解凍可視同為增、減，簡化模型，下面以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整個落庫，后批量處理
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/68068.html
摘要：通常偽同步方案采用三件套日志校驗位廣播消息來完成一次完整的請求流程圖一般如下請求階段同步請求調用，核心要素追加寫入日志，變更校驗位，完成同步調用此處追加寫保證了快速寫入，校驗位來保證數據的最終寫入成功。 話接上回，上篇闡述了什么是熱點賬戶，基本財務賬戶如何設計，冪等健和鏈式設計！本篇將針對熱點賬戶在實踐中引發的問題，梳理和拆解業務流，分析問題點，提出七種常用解決方案。 一、性能問題初現...
摘要：啟用嚴格傳輸安全協議來進一步減少遭受攻擊的可能。這些措施將使攔截流量變得極其困難。這種情況在酒吧賓館火車和其他公共場所非常普遍。部分使用也將面臨被動攔截的風險。 許多Web開發者都知道SSL，但常見的情況是SSL沒有完整地部署或者沒有部署在它應該部署的地方。這篇關于何時及如何部署SSL的簡要指南，將幫助你避免大多數常見錯誤。 要點 如果你有任何機密信息，或者你要進行用戶登陸，哪怕...
閱讀 3952·2021-11-24 09:38
閱讀 1421·2021-11-19 09:40
閱讀 2778·2021-11-18 10:02
閱讀 3691·2021-11-09 09:46
閱讀 1765·2021-09-22 15:27
閱讀 3110·2019-08-29 15:24
閱讀 997·2019-08-29 12:40
閱讀 1683·2019-08-28 18:24
