從儲值卡（會員卡）充值業務看分佈式事務的設計

公司有一項儲值卡充值業務：客戶在微信公衆號開通儲值卡服務，經過微信支付往卡里面充值，充值成功後客戶可收到消息通知，並進行消費。

看起來是一項很簡單的業務，最初咱們儲值卡團隊的實現也確實很簡單。咱們看看最初的實現：

相信聰明的你一眼就能看出問題：

1. 壓根沒有考慮分佈式事務一致性，好比第 12 步根本沒有考慮卡系統充值失敗的狀況該如何處理，而是默認其必定能成功；
2. 大部分的處理都是放在前端業務系統（除了這裏的公衆號系統，還有 POS 機系統，而 POS 機是經過調公衆號系統接口來實現的）；
3. 第 4 步直接下單，第 5 步直接調微信支付，壓根沒有跟卡系統有任何通訊：這裏默認用戶的充值行爲必定是合法的；
4. 在微信的支付回調中（第 10 步日後），是先處理一系列業務邏輯，最後才調充值接口，這裏也是默認卡充值必定能成功；

看到這裏你可能會大呼開發人員是否是沒長腦子？

實際狀況是，這個版本的開發是幾年前的事情了，那時候公司仍是創業早期，第一目標是儘快上線能用，並且客戶量沒有那麼大，雖然中間也出現過一些數據不一致的狀況，也都經過人工處理了事了。

隨着公司業務的發展，用戶量愈來愈大，並且還要和第三方合做（儲值卡做爲一種支付方式提供給第三方使用），問題出現得也愈來愈頻繁，不得不將這塊提上重構議程。

那麼，針對上面提的幾點問題，咱們大致能想到以下重構項：

1. 將充值業務邏輯從前端系統剝離，作成單獨的服務；
2. 在下單前，先調一下卡系統接口，檢查用戶的充值行爲是否合法，避免後面沒必要要的麻煩；
3. 在支付回調中，處理充值失敗的場景；

初步設計以下：

這裏咱們重點討論下對第 14 步（卡充值接口返回結果）的處理：

1. 若是返回充值成功，那萬事大吉，該幹嗎幹嗎；
2. 若是失敗呢？可能的處理方式以下：
   1. 繼續重試，最多重試 3 次，若是成功了，萬事大吉；
   2. 若是上面重試仍是失敗，那麼調微信退款，並將訂單狀態改爲充值失敗；

騷年你等等！
你說什麼？重試失敗了就去退款？

實踐中，遠程調用失敗的一個很大緣由是網絡超時（而超時的很大緣由又是對方負載太高），而面對超時，咱們是不知道對方到底有沒有處理成功的，萬一這邊把錢退掉了，那邊又充值成功咋辦？（咱們是 SaaS 服務商，這時真正的損失方是咱們的商戶，而商戶無疑會找咱們索賠的）

一種方案是：
在屢次重試失敗後發起微信退款以前，先調卡系統查詢接口，若是查詢結果是充值成功，則不退款，繼續後續流程，不然發起退款；

該方案在實際中也基本行不通，由於若是那段時間網絡有問題或者對方服務器負載高，查詢也有很大機率失敗，或者就算查成功了並返回充值記錄不存在，也有可能以前調的充值接口還在跑（好比處於鎖等待狀態）。

有人可能會說，不要緊啊，就算退款後充值成功了，那後面經過人工或者系統發現數據問題再處理掉不就好了嗎？

問題在於，若是在發現問題以前，用戶已經從卡上消費掉了呢（好比用戶當場衝1000 而後立馬消費掉，這在咱們實際場景中是常常發生的，由於不少商戶會搞充值活動，好比衝1000 送 200）？把卡餘額扣成負數？（這不是我杜撰的，在咱們老儲值卡系統就出現過幾回這種狀況，當時是直接由公司給商戶賠錢）

所以，關鍵在於，當充值中心不知道卡系統有無充值成功的狀況下，須要內部假定充值成功了。

最終，咱們決定用定時任務來解決。在微信支付回調中，若是屢次調卡充值接口失敗，咱們不發起退款，也不進行後續流程，而是在數據庫中寫入一條異常記錄，而後結束本次處理。

在定時任務中（好比 10 分鐘一次），咱們取出那些異常記錄，調卡系統相關接口覈對最終狀態，若是充值成功了，則補充執行充值成功的後續流程，不然發起微信退款，並執行其餘充值失敗流程（如改訂單狀態，給用戶發通知、回調業務系統等）。

爲了防止錢退了後卡又充值成功，定時任務中只處理 1 小時前的數據。

另外一個隱藏的問題是，在前面的充值流程中，直到微信支付回調，卡系統都沒有關於此次充值行爲的任何記錄。這可能會致使後續一系列問題，其中一個問題是，在最初下單（步驟 5）到最終充值（步驟 13）這段時間內，一旦任何變量（充值規則）發生改變，此次充值就有可能會失敗（或者致使數據差錯）。這個時間差短則幾十毫秒，長則幾分鐘十幾分鍾都有可能。另外一個次要問題是，一旦發生充值異常，卡系統自身是不知情的（由於沒有任何記錄），對卡系統的任何查詢也都不會反映此次充值行爲。

爲了解決該問題，咱們引入預充值的概念。在下單後調微信支付前，先同步調卡系統的預充值接口，該接口計算充值合法性並生成一條預充值記錄，該記錄包含充值帳號、充值金額、支付金額、充值單號等關鍵信息，狀態爲「充值中」。

在微信支付回調中，將預充值狀態改爲「充值成功」，並處理一些其餘邏輯。
綜合，最終方案如圖：

總結：

1. 任何涉及到分佈式事務的地方都是複雜的，必須當心設計；
2. 遠程過程處理不具備時序性，設計時必須考慮進去（如退款後最終又充值成功的狀況）；
3. 現實中的設計不少時候作不到完美，咱們要作的是保證出現異常的機率最小化並設置最終檢查哨兵（上面的定時任務）；
4. 就算增設了哨兵，也不排除須要人工干預的可能性，於是在設計上儘可能保證須要人工干預時有跡可循、方便處理；
5. 遠程調用須要有重試機制（上面只說了對充值接口的重試，其實其餘接口也同樣須要有重試機制）；
6. 記住一句話：網絡老是不可靠的；