對於支付計費系統而言，餘額的正確性關係到整個財務系統的穩定，但在高併發場景下若處理不當，財務資料很容易出現問題（如：餘額為負、餘額和流水資料對不上）。

1、使用者量訪問量大導致的應用高併發

這種高併發只是應用層面的高併發，和其它應用一樣是不可避免的，業務要發展，使用者一多必然會出現這種現象。處理措施一要就是用分散式部署 + 叢集 + 負載均衡來處理即可。

2、高併發下資料庫操作不當導致長時間鎖

高併發下如果程式碼層面處理不當很容易導致資料庫長時間鎖定，操作處於長時間等待阻塞狀態，進而影響整個系統的穩定性。

1、必須使用事務確保ACID

即：事務的原子性、一致性、隔離性、永續性，避免出現髒資料。

千萬不要在把餘額從資料庫中讀取出來，減掉扣費金額，再存入資料庫！這種程式碼層面操作資料絕對會出現髒資料。

具體是悲觀鎖還是樂觀鎖看設計需要。

2、減少行鎖佔用時間

這個主要是程式碼層面要求設計合理，將一些不必要的耗時操作放在獲取行鎖之前、事務之外去執行，減少每次請求的行鎖佔用時間，這樣效能會明顯提升。

3、不設定餘額欄位

這種是根據流水明細來計算餘額的，這種可靠性高，但不適用於實時性要求高的系統。

高併發扣費用傳統資料庫是支撐不了的，如果允許少量欠費，可以緩衝後扣費。redis是比較可行的。用redis叢集。

餘額扣減是一個涉及到金錢的問題，對於涉及到金錢的問題，首先我們要想到的是如何確保資料安全，然後再說如何解決併發。

餘額扣錢一般會涉及到多個表，比如餘額表，流水錶等，要保證資料的準確安全，我們必須要要保證餘額表和流水錶同步操作，也即餘額表的每一次操作，在流水錶中都要有相應的流水記錄，否則就可能產生髒資料，影響對賬，甚至威脅使用者賬戶安全。

保證餘額表和流水錶等同步操作，我們可以使用事務，這事務可以是資料庫事務，也可以是分散式事務。透過事務操作來保證餘額表和流水錶中的操作要麼同時成功，要麼同時失敗。

至於高併發，我們既可以使用叢集分散流量減少併發，也可以透過鎖保證程式順序執行阻止併發。

透過事務和鎖的雙管齊下，高併發下的餘額扣減就可以順利解決了。