核心記帳業務可用jdk7的PriorityBlockingQueue優先阻塞隊列結合樂觀鎖實現

-- 一、優先級阻塞隊列

當前核心記帳業務是悲觀鎖實現，但考慮到高併發和死鎖的問題，能夠用PriorityBlockingQueue優先阻塞隊列結合樂觀鎖實現，對於併發時出現鎖沒法update時能夠從新進入隊列並調整優先級進行記帳處理。

新方案：樂觀鎖：PriorityBlockingQueue<T> 優先級隊列串行化記帳請求，樂觀鎖處理帳戶表相關的數據一致性問題，當數據不一致時將優先級調整再次進入記帳隊列。

PriorityBlockingQueue是無界隊列，與緩存線程池同樣，使用時要千萬注意控制，否則很容易消耗系統全部資源致使崩潰。

老方案：悲觀鎖： 更改帳戶表餘額update語句：update t_account set amount = amount - quantity where amount >= quantity and ID = 12345

                        一、記流水，二、加減單邊主帳戶餘額（悲觀鎖），三、更新流水（主帳戶記帳成功），四、異步請求處理完成單邊帳，更新流水狀態，更新會計流水

 

--- 二、熱點帳戶

帳務系統會由於複式記帳法業務而在交易到達必定數量級後成爲熱點，因此從交易流水就應該和帳務核心分開，交易流水和單式記帳做爲一個層次，而後再請求帳務核心和會計核心。這樣也就緩衝了熱點，後面分開的會計引擎，且調單邊帳的功能不能少了。

 

我的帳戶=資產，餘額方向和發生方向都應該是雙方，在餘額變更時經過操做層面來判斷。也能夠設計成一方且不可紅字，也能夠設計成雙方共同反應，同時有借方餘額和貸方餘額，只是在餘額更新的時候多加條件判斷，防止紅字。(◎﹏◎) 綜合仍是共同反應比較好，餘額字段保留，不過須要做爲被動觸發計算的字段，不會實時更新。

 

猜想：一、針對須要調銀行網關的交易，調用網關實現交易後直接insert成功的單邊流水，若是失敗則insert失敗的流水。

         二、針對不調銀行網關直接用帳戶餘額的交易，則用帶鎖的update實現餘額變更，成功後須要插入成功狀態的流水，不成功則插入失敗的流水。

　　　　　　流水插入失敗必要回滾餘額變更的update語句。這樣作還有一個前提就是已開戶且激活的有效用戶。

　　　　　　注意：在2中再也不是insert流水再等業務處理完畢update流水。