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

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

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

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

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. 記住一句話：網路總是不可靠的；