漸漸地我們發現自己塊老樂
對於支付計費系統而言，餘額的正確性關係到整個財務系統的穩定，但在高併發場景下若處理不當，財務數據很容易出現問題（如：餘額為負、餘額和流水數據對不上）。
支付計費系統高併發種類
1、用戶量訪問量大導致的應用高併發
這種高併發只是應用層面的高併發，和其它應用一樣是不可避免的，業務要發展，用戶一多必然會出現這種現象。處理措施一要就是用分佈式部署 + 集群 + 負載均衡來處理即可。
2、高併發下數據庫操作不當導致長時間鎖
高併發下如果代碼層面處理不當很容易導致數據庫長時間鎖定，操作處於長時間等待阻塞狀態，進而影響整個系統的穩定性。
高併發場景下餘額扣減的建議
1、必須使用事務確保ACID
即：事務的原子性、一致性、隔離性、持久性，避免出現髒數據。
千萬不要在把餘額從數據庫中讀取出來，減掉扣費金額，再存入數據庫！這種代碼層面操作數據絕對會出現髒數據。
具體是悲觀鎖還是樂觀鎖看設計需要。
2、減少行鎖佔用時間
這個主要是代碼層面要求設計合理，將一些不必要的耗時操作放在獲取行鎖之前、事務之外去執行，減少每次請求的行鎖佔用時間，這樣性能會明顯提升。
3、不設置餘額字段
這種是根據流水明細來計算餘額的，這種可靠性高，但不適用於實時性要求高的系統。
網絡圈
高併發扣費用傳統數據庫是支撐不了的，如果允許少量欠費，可以緩衝後扣費。redis是比較可行的。用redis集群。
皮卡P
用互斥鎖，像線程鎖、信號量這些。如果對實時性要求不高，扔到一個隊列中異步處理也是個辦法。
光明右使8787
什麼場景下有好高併發扣款額，銀行那邊都很少有高併發扣款的，給個場景。
日暮丶途遠1
這是一個業務場景都沒說清楚的問題，回答結束。
胖大C紀錄片
只寫操作，複式記賬，只追加計費記錄。只讀操作，定時做簡單的累加統計。即使丟單，也不會有過大損失。
分享到:
