支付平台正確性保證

05-15

支付平台必須保證數據正確性，保證數據並發安全性，保證數據最終一致性。數據一致性場景大致可以分為弱一致性和強一致性，所謂的弱一致性，就是有可能在某個時刻數據非一致，但是到達某個時間點以後總能保持一致，也即我們所說的最終一致性。而強一致性就是需要保證數據的一致性是實時的，每一時刻都保持一致。我們支付平台通過如下幾種方式來保證數據一致性：

?分散式鎖

這個比較容易理解，就是在操作某條數據時先鎖定，可以用redis或zookeeper等常用框架來實現。比如我們在修改賬單時，先鎖定該賬單，這樣如果該賬單有並發操作，後面的操作只能等待上一個操作的鎖釋放後再依次執行。分散式鎖的優點是能夠保證數據強一致性，但是高並發場景下可能有性能問題。

?消息隊列

消息隊列是為了保證最終一致性，我們需要確保消息隊列有ack機制，客戶端收到消息並消費處理完成後，客戶端發送ack消息給消息中間件，如果消息中間件超過指定時間還沒收到ack消息，則定時去重發消息。比如我們在用戶充值完成後，會發送充值消息給賬戶系統，賬戶系統再去更改賬戶餘額。消息隊列的優點是非同步、高並發，缺點是有一定延時、數據弱一致性，並且必須能夠確保該業務操作肯定能夠成功完成，不可能失敗。比如充值，收到錢後業務上來講就是代表充值成功了，用戶餘額延遲幾秒更新沒有影響，因此可以採用消息隊列非同步更新餘額。

?TCC模式

TCC模式把操作分成 Try-Confirm-Cancel三階段，只要Try成功了，Confirm一定會成功，採用類似於兩階段提交的方式來確保數據一致性。比如我們用戶支付時，用戶可能會同時採用會員卡和微信支付，而微信支付依賴於第三方系統，我們用TCC模式來確保微信支付成功後會員卡消費肯定能成功。具體來說就是在調起微信支付時，我們先Try一下，把用戶會員卡凍結某筆金額，微信支付成功後，我們再Confirm一下，核銷會員卡凍結的錢。TCC的優點是數據強一致性，缺點是引入了中間狀態和操作，不一定所有的業務都可以支持。

?對賬系統

對賬系統是最魯棒的技術，最適用於財務系統。對賬貫穿整個支付流程，資金流和數據流在各個系統中的流轉都會通過對賬來核實。優點是魯棒性強，基本適合任何場景，缺點是延時比較多，如果對賬有差異，需要人工介入處理。

?多版本並發控制（MVCC）

也就是我們常說的樂觀鎖，在用戶數據上加一個版本號，每次更新前都先取出版本號，更新時先比對版本號，版本號一致才更新並把版本號加一。優點是性能高，缺點是高並發場景下更新可能失敗，需要重試。

?補償事務

先操作，如果操作失敗再補償。比如我們用戶提現，再申請提現時直接從用戶賬戶餘額中扣除該提現金額，然後再調用三方系統去提現，如果提現最終失敗，我們再把該扣除的餘額給用戶補上。優點是非常簡單，缺點是不一定所有的業務操作都可以補償，只能實現數據弱一致性。