0.引言
在日常生活中，從線下的超市購物到線上的外賣點餐、電商網購等，支付無時無刻不在發生，不論是通過現金、pos機刷卡還是微信支付寶等第三方支付。線上支付有著及時便捷一氣呵成的極致體驗，當然也有少數的時候體驗不夠絲滑，比如早期我們在PC版12306買火車票，當支付完成後，訂單的支付狀態卻經常不能及時更新，會有一段時間的延遲，有時甚至會等待很長時間處在未支付狀態。
在支付的過程中由於各種各樣的原因（比如外部渠道處理出了問題，異步回調遲遲不來）導致流程走了一半停了下來，用戶看到訂單依然是未支付狀態，會不知所措，此時就需要一種機制來推動完成這筆交易。本文就以三方支付系統中的補單機制為例，來介紹一種較為通用的單據補償模式。
1.三方支付系統簡介
1.1什麼是三方支付
所謂第三方支付，就是和各大銀行籤約，獨立於商戶和銀行，具備一定實力和信譽保障的，為商戶與消費者提供支付結算服務的第三方獨立機構。它是處於買方和賣方之間具備公信力的第三方，承擔擔保人和資金託管人的角色。三方支付也可以稱為虛擬帳戶支付，由消費者在第三方支付機構開設虛擬帳戶，並用虛擬帳戶中的資金進行支付。業界常見的三方支付有支付寶、微信支付、美團支付、京東支付等等。
1.2三方支付中的交易&支付系統
交易是什麼，最直觀的描述就是「一手交錢、一手交貨」，交易會使買賣雙方形成債權和債務關係。交易的存在是支付發生的前提，用戶通過使用某種支付方式去完成交易。交易是支付流程的驅動者，根據具體場景組合不同的支付指令，來完成交易資金的轉移。
支付是交易處理資金流的工具，目的是清償債權和債務關係；支持多種支付方式（如銀行卡支付、餘額支付、優惠券組合支付、類似花唄的信用支付等），負責對接帳務、會計、計費系統等資金處理能力，接收支付指令，驅動完成資金交換。將實際的支付行為（實際資金）與內部的記帳（虛擬資金）相結合，保證虛實一致。
三方支付整體業務架構如圖1所示，其中交易核心與支付核心在業務劃分上處於"收單支付域"，具備普通交易的收款、付款、退款及充值、轉帳與提現等常見功能，還包括了支撐電商業務的合單支付、擔保與分帳的能力。其中交易與支付核心都有一個異常查補模塊，它囊括了所有業務的補償流程，也是本文主要介紹的部分。
圖1.三方支付業務架構
2.什麼是補單&為什麼需要補單
一筆交易在支付過程中由於鏈路中的各種異常而中斷，此時的交易處在一種中間狀態，這種情況俗稱"卡單"，即卡在那裡不動了，沒有繼續向下推進。還有一種情形，支付核心向渠道發起了扣款，渠道受理後，銀行卡扣款成功，但由於種種原因沒有向支付核心發起回調，導致這筆支付沒有完成，用戶沒有享受到相應權益，但銀行卡的錢已經扣了，這種情況稱為「掉單」。
不管是卡單還是掉單，都是處在中間態的訂單。補單就是將處在中間態的訂單進行補償，直到推進到終態（成功或失敗）。補單一般有兩個關鍵點，一個是補償的有效性，極端情況下可能補償多次都不成功，不能就此放棄了，需要有兜底的機制；另一個是補償的及時性，因為交易掛起的時間越長，用戶的體驗越差。
交易核心和支付核心的補單相得益彰，具有一定相似程度的設計與實現，我們就以支付核心的補單為例介紹下異常補單機制。
3.補單是如何實現的
本章首先了解一下業務流程，說明一下實現補單需要的前提基礎，然後介紹一下補單機制的演進路線，每個版本存在的問題以及在下一個版本是如何解決的。
3.1有限狀態機與冪等性
標識資金操作的有限狀態機
我們首先以用戶發起一筆餘額提現為例，說明下業務流程，簡化後如圖2所示。
圖2.餘額提現流程
首先生成支付訂單，然後請求帳務系統，扣減用戶帳戶下的餘額，接著向外部渠道發起付款操作，資金操作完成後統一處理結果並更新單據信息，最後還有一些對上下遊的異步通知，形式上包括消息和RPC回調。
我們將每個關鍵資金操作的狀態記錄落庫，如下表所示。其中出款即錢從哪裡來，入款即錢到哪裡去，衝正即回滾交易。在提現場景下就是從用戶支付帳戶出錢，到用戶的銀行卡去。其他場景比如充值（銀行卡->用戶支付帳戶），會有不同的資金流向。表中最後兩行加粗的場景還沒有達到終態，是我們需要去補償的。
為了便於理解，我們在這裡省略了衝正的相關操作，一次餘額提現流程的狀態機轉換如圖3所示。
圖3.附帶狀態機轉換的餘額提現流程
可重入與冪等性保證
發起一次支付會涉及到多個系統間調用，由於網絡原因導致的通信超時是常見的問題。同時上遊系統也可能會重新發起請求，這需要我們的系統保證操作結果的冪等性。少數用戶也可能會有多個終端同時操作帶來的並發請求，需要我們保證接口的可重入性。除了服務自身，我們的下遊依賴同樣也需要保證其接口具有同樣的能力。
先說一說什麼是可重入與冪等性。
可重入：在並發請求下可以保證正確性。冪等性：重複多次相同的輸入，獲得相同的輸出。冪等性在技術上其實也包含了可重入的要求。具體到業務中，冪等性是針對一筆已經到達終態的支付而言的，對於初次未能拿到最終業務結果的請求，再次發起調用的結果可以是不同的（處理中->處理成功或失敗）。那麼我們如何保證業務流程的可重入與冪等性呢？我們分別拆解每一步來看：
生成支付單：首先支付單據可以將業務方傳遞的可保證唯一性的外部訂單號作為唯一索引，插入資料庫時若發生唯一索引衝突，則將查詢已有數據進行冪等參數校驗，若與當次請求的參數完全一致說明是重複請求，可使用DB中的支付單繼續推進後續流程；若不一致則返回錯誤。資金處理流程：帳戶和渠道系統各自保證其接口冪等性。我們也維護了每個下遊操作的狀態，根據狀態機決定是否要繼續推進，儘量不向下遊輸出重複流量。比如支付單已經完成了所有資金處理，狀態機已經是終態，那麼接口可以直接返回相應結果。更新支付單信息，先將支付單加行級排他鎖，再進行更新，保證多個並發請求只會有一個成功。異步通知，在支付單推進到終態後進行。有了可重入與冪等性保證，我們就可以大量地復用正向流程來實現補單接口。
3.2初始版
一般來說最常見的補單形式是設置一個定時任務，定時去掃表完成業務補償，實現比較簡單，但是及時性不夠，對於收款轉帳類的交易而言用戶體驗不佳。我們採用了通過消息隊列進行即時補償的方式，如圖4所示。補償消費者並沒有去做補償工作，而是解析消息然後通過RPC調用支付核心暴露的補償接口。為什麼不在消費者中直接補償？這麼做主要是考慮將邏輯收斂到一處便於維護。
圖4.餘額提現發生異常時的補單流程
當然，補單可能依然失敗，我們可以再次發送補償消息。但不能一直這樣循環下去，所以需要設置一個最大重試次數，超出後不再發送。當補償多次都不成功時，一般是下遊系統出了問題，這時我們需要放緩補償的頻次，隨著重試次數增加，會讓每次補償時間間隔逐漸增大，通過RocketMQ的延時消息實現。
這裡有三個很容易想到的問題：
如果異常消息發送失敗，上遊也沒有重試機制，這筆訂單就可能一直掛在這裡不了了之了，如圖5所示。補償消費者請求支付核心補單時不成功，可能是超時但實際補償成功了，或者是請求壓根沒有過去，如圖6所示。如果重試達到最大次數依然沒有成功，這筆單子該怎麼處理。圖5.補償消息發送失敗
圖6.補償消息消費失敗
3.3改進版
針對問題1，如果重試依然發送失敗，我們通過引入一張異常消息表，將發送失敗的消息落庫來解決。表中記錄了訂單號、當前的重試次數、異常分類、記錄狀態、消息體等欄位。如果圖6中的第4步消息發送失敗，就將這筆訂單放入DB中的一張異常表中，會設置一個定時任務去處理。以目前RocketMQ的可用性來說，異常數據很少會出現。如圖7所示。
圖7.針對消息生產/消費異常的改進版-1
對於第2個問題，如果補償消費者調用支付核心失敗，補償消費者HandleMessage會向上層拋出error，利用RocketMQ的梯度重試機制，當消費重試次數達到一定上限後會進入死信隊列。如圖8所示，這種情況一般是服務或網絡出了問題，待恢復之後，可以從死信隊列拉取這些消息再統一處理。
圖8.針對消息生產/消費異常的改進版-2
當然還有更極端的情況，請求MQ和DB都失敗了咋辦？以目前MQ和DB的可用性來說，同時失敗這種基本可以不用考慮，報警人工介入即可。
針對問題3，如果重試超過最大次數，依然補償不成功，一般是下遊依賴出了問題。這種情況我們也將它放進異常表中。
對於這兩類漏網之魚，需要支持單條/批量支付單補償的運營能力以供人工介入；最好有一個在業務低峰期運行的兜底任務，掃描業務單據表，將一段時間內還未完成的訂單進行補償。
另外，兜底任務可能造成消息的短暫堆積，影響線上的實時補償流程推進，對此可以使用獨立的隊列隔離開來。
3.4最終版
其實如果只是異步通知類的操作出現了異常，並沒有必要每次都重新走一遍完整業務流程，缺啥補啥即可。因此我們將異常劃分為多種類型，將一些異步操作和業務處理劃分開來，進行精細化的處理：
通知下遊的MQ失敗，就將這個消息體重發一次即可；通知交易的回調RPC失敗，可將RPC請求序列化到消息體中，補償時通過反序列化消息體中的RPC請求，直接再發起一次RPC即可；對於更新DB失敗，將更新參數序列化到消息體中，補單時再次發起一次更新；如果在業務處理時遇到了異常情況，需要再走一遍業務補償；圖9以這幾種異常為例，說明了每種補償類型的消息參數。
圖9.分類補償
我們最終的補單體系見圖10，它既通過即時消息保證了補償的及時性，是主動出擊之茅；也利用延時消息重試、落地失敗消息的異常表與兜底任務保證了補償的有效性，是萬無一失之盾。不僅可用於支付單據的補償，通過保證流程的可重入性，也可作為一種通用解決方案，但不適用於無狀態、不可重入的業務形態。
圖10.異常補償體系
4.總結
本文首先介紹了什麼是補單，接著基於三方支付系統的實現完整闡述了補單機制的演進過程，最終演化為一種相對通用的異常處理模式，即基於消息隊列、有限狀態機與多重任務兜底的業務層最終一致性保障機制，供大家參考指正。