在當(dāng)今的支付業(yè)務(wù)領(lǐng)域，其涉及的環(huán)節(jié)繁多，涵蓋了創(chuàng)建訂單、發(fā)起支付、等待第三方回調(diào)、退款以及關(guān)閉等多個(gè)關(guān)鍵步驟。

由于環(huán)節(jié)復(fù)雜且異常場(chǎng)景層出不窮，如果僅僅依賴一個(gè)簡(jiǎn)單的 status 字段來(lái)隨意更新訂單狀態(tài)，極易引發(fā)邏輯混亂、漏單現(xiàn)象，同時(shí)也會(huì)給后續(xù)的審計(jì)工作帶來(lái)極大的困難。

為了解決這些問(wèn)題，眾多支付系統(tǒng)紛紛引入了狀態(tài)機(jī)（State Machine）這一強(qiáng)大工具，用于管理支付訂單在不同階段的狀態(tài)轉(zhuǎn)移。與此同時(shí)，配合使用狀態(tài)變更記錄表（也稱為歷史表）進(jìn)行詳細(xì)記錄，為后續(xù)的審計(jì)和問(wèn)題排查提供有力支持。

圖片

一、為何支付系統(tǒng)需要狀態(tài)機(jī)

1. 業(yè)務(wù)復(fù)雜度的應(yīng)對(duì)

支付流程猶如一幅錯(cuò)綜復(fù)雜的畫(huà)卷，從訂單創(chuàng)建伊始，到支付成功或失敗，再到可能的退款或關(guān)閉操作，其間存在著各種各樣的中間狀態(tài)和異常情況。

例如，用戶可能因?yàn)楦鞣N原因遲遲不進(jìn)行付款操作；第三方回調(diào)信息可能由于網(wǎng)絡(luò)等因素丟失；部分退款的情況也時(shí)有發(fā)生。

這些復(fù)雜的業(yè)務(wù)場(chǎng)景使得簡(jiǎn)單的狀態(tài)管理方式難以勝任，而狀態(tài)機(jī)的引入則為解決這些問(wèn)題提供了有效的途徑。

2. 提升可維護(hù)性與可審計(jì)性

• 可維護(hù)性：狀態(tài)機(jī)能夠清晰地列出狀態(tài)與事件之間的對(duì)應(yīng)關(guān)系，就像一張精確的地圖，為團(tuán)隊(duì)成員指引方向。這避免了團(tuán)隊(duì)成員隨意修改訂單狀態(tài)，減少了溝通成本和排查問(wèn)題的時(shí)間。關(guān)注工眾號(hào)：碼猿技術(shù)專欄，回復(fù)關(guān)鍵詞：1111 獲取阿里內(nèi)部Java性能調(diào)優(yōu)手冊(cè)！團(tuán)隊(duì)成員可以根據(jù)狀態(tài)機(jī)的規(guī)則，快速了解系統(tǒng)的運(yùn)行邏輯，提高開(kāi)發(fā)和維護(hù)的效率。
• 可審計(jì)性：支付業(yè)務(wù)涉及資金流動(dòng)，受到嚴(yán)格的監(jiān)管和合規(guī)要求。因此，對(duì)每一步狀態(tài)變更進(jìn)行詳細(xì)的留痕記錄是必不可少的。狀態(tài)變更記錄表可以記錄下?tīng)顟B(tài)變更的時(shí)間、原因、操作者等重要信息，為后續(xù)的審計(jì)工作提供了完整的證據(jù)鏈。

3. 有序處理異常場(chǎng)景

在支付過(guò)程中，異常場(chǎng)景時(shí)有發(fā)生，如第三方回調(diào)可能延遲或失?。挥脩艨赡茉谥Ц吨型救∠唵?；退款過(guò)程需要多次與第三方進(jìn)行確認(rèn)等。

狀態(tài)機(jī)的引入使得這些異常場(chǎng)景的處理更加有序，能夠確保系統(tǒng)內(nèi)狀態(tài)的一致性。通過(guò)狀態(tài)機(jī)的規(guī)則，可以對(duì)不同的異常情況進(jìn)行分類處理，避免系統(tǒng)出現(xiàn)混亂。

綜上所述，對(duì)于中大型支付系統(tǒng)而言，狀態(tài)機(jī)幾乎是不可或缺的設(shè)計(jì)工具，它能夠幫助系統(tǒng)更好地應(yīng)對(duì)復(fù)雜的業(yè)務(wù)場(chǎng)景，提高系統(tǒng)的穩(wěn)定性和可維護(hù)性。

二、常見(jiàn)支付狀態(tài)的解析

在實(shí)際的支付業(yè)務(wù)中，支付狀態(tài)的定義并非一成不變，而是需要根據(jù)具體的業(yè)務(wù)需求進(jìn)行靈活調(diào)整。下面為大家呈現(xiàn)一個(gè)常見(jiàn)且相對(duì)完整的支付狀態(tài)集合，你可以根據(jù)自身業(yè)務(wù)的特點(diǎn)進(jìn)行增減或合并。

1. CREATED（已創(chuàng)建）

當(dāng)訂單在支付中心成功生成，但尚未正式發(fā)起支付時(shí)，訂單處于此狀態(tài)。這是訂單生命周期的起始階段，標(biāo)志著訂單的初步創(chuàng)建。

2. PENDING（待支付）

一旦向第三方發(fā)起支付請(qǐng)求，或者生成了支付鏈接/二維碼供用戶進(jìn)行支付操作，但尚未收到最終的支付結(jié)果時(shí)，訂單進(jìn)入待支付狀態(tài)。此時(shí)，系統(tǒng)需要等待用戶完成支付或第三方返回支付結(jié)果。

3. PROCESSING（支付中 / 處理中）

部分支付渠道會(huì)返回「處理中」的狀態(tài)信息，這意味著第三方需要一定的時(shí)間來(lái)完成扣款確認(rèn)操作。在某些業(yè)務(wù)場(chǎng)景中，可能會(huì)將「待支付」和「支付中」這兩個(gè)狀態(tài)合并為一個(gè)狀態(tài)，以簡(jiǎn)化業(yè)務(wù)邏輯。

4. SUCCESS（支付成功）

當(dāng)收到第三方支付成功的回調(diào)信息，或者主動(dòng)查詢到支付成功的結(jié)果時(shí)，訂單正式完成支付，進(jìn)入支付成功狀態(tài)。這是支付流程的一個(gè)重要里程碑，標(biāo)志著交易的順利完成。

5. FAIL（支付失?。?/h3>

若第三方支付明確表示失敗，或者用戶超時(shí)未付款，訂單將進(jìn)入支付失敗狀態(tài)。一旦進(jìn)入此狀態(tài)，通常情況下訂單將無(wú)法再進(jìn)行支付操作。

6. REFUNDING（退款中）

對(duì)于已經(jīng)支付成功的訂單，當(dāng)用戶或系統(tǒng)發(fā)起退款請(qǐng)求后，訂單進(jìn)入退款中狀態(tài)，此時(shí)需要等待第三方的退款結(jié)果。在這個(gè)階段，系統(tǒng)需要與第三方進(jìn)行溝通，確保退款操作的順利進(jìn)行。

7. REFUNDED（退款成功）

當(dāng)?shù)谌酱_認(rèn)退款成功后，訂單進(jìn)入退款成功狀態(tài)。如果是部分退款的情況，需要在訂單或退款表中詳細(xì)記錄已退金額和剩余可退金額，以便進(jìn)行后續(xù)的管理和查詢。

8. CLOSED（已關(guān)閉 / 已取消）

若訂單在支付成功之前被取消，例如用戶主動(dòng)取消訂單或系統(tǒng)因超時(shí)自動(dòng)關(guān)閉訂單，訂單將進(jìn)入已關(guān)閉狀態(tài)。一旦訂單處于此狀態(tài)，將不可再進(jìn)行支付或退款操作。

這些狀態(tài)基本涵蓋了常見(jiàn)的支付生命周期。你可以根據(jù)實(shí)際業(yè)務(wù)場(chǎng)景的需求，對(duì)狀態(tài)進(jìn)行簡(jiǎn)化或細(xì)化。例如，如果業(yè)務(wù)場(chǎng)景不需要「PROCESSING」或「REFUNDING」?fàn)顟B(tài)，可以將其去除；若需要更加精細(xì)的退款流程，也可以進(jìn)一步細(xì)化「部分退款」「多次退款」等狀態(tài)。

三、典型狀態(tài)流轉(zhuǎn)示例詳解

狀態(tài)機(jī)的核心機(jī)制在于通過(guò)當(dāng)前狀態(tài)和觸發(fā)事件來(lái)確定下一個(gè)狀態(tài)。下面為大家展示一個(gè)簡(jiǎn)化的示例，清晰地呈現(xiàn)了常見(jiàn)的事件觸發(fā)和狀態(tài)變化情況。

圖片

以上示例僅為通用情況，實(shí)際業(yè)務(wù)中可能會(huì)根據(jù)部分退款、多次退款、多渠道回調(diào)等復(fù)雜情況進(jìn)行更加精細(xì)的設(shè)計(jì)。

四、狀態(tài)變更記錄表的設(shè)計(jì)要點(diǎn)

4.1 為何需要單獨(dú)的記錄表

• 審計(jì)與追溯：資金相關(guān)的業(yè)務(wù)對(duì)留痕要求極高，通過(guò)狀態(tài)變更記錄表，可以在事后詳細(xì)查看每一次狀態(tài)變化發(fā)生的時(shí)間、原因以及操作者等重要信息。關(guān)注工眾號(hào)：碼猿技術(shù)專欄，回復(fù)關(guān)鍵詞：1111 獲取阿里內(nèi)部Java性能調(diào)優(yōu)手冊(cè)！這為審計(jì)工作提供了有力的支持，確保業(yè)務(wù)操作的合規(guī)性。
• 問(wèn)題排查：當(dāng)用戶提出投訴或系統(tǒng)出現(xiàn)故障時(shí)，狀態(tài)變更記錄表可以幫助我們快速還原訂單的完整生命周期，定位問(wèn)題的根源。通過(guò)查看狀態(tài)變更的歷史記錄，我們可以了解訂單在各個(gè)階段的狀態(tài)變化情況，找出可能存在的問(wèn)題。
• 統(tǒng)計(jì)分析：基于狀態(tài)變更表，我們可以進(jìn)行豐富的統(tǒng)計(jì)分析工作。例如，統(tǒng)計(jì)訂單在各狀態(tài)停留的時(shí)間分布，了解業(yè)務(wù)流程的效率；分析失敗率和退款率等指標(biāo)，為業(yè)務(wù)優(yōu)化提供數(shù)據(jù)支持。

4.2 表結(jié)構(gòu)示例

常見(jiàn)的狀態(tài)變更記錄表（也可稱為 payment_status_history 或 payment_order_history 等）可以按照以下結(jié)構(gòu)進(jìn)行設(shè)計(jì)：

圖片

需要注意的是，一個(gè)訂單從創(chuàng)建到完成，可能會(huì)多次變更狀態(tài)，每次狀態(tài)變更都需要插入一條新的記錄，而不是只保留一條記錄。各字段的含義如下：

• order_id：用于區(qū)分該記錄屬于哪個(gè)訂單，確保記錄與訂單之間的關(guān)聯(lián)關(guān)系。
• from_status / to_status：記錄本次狀態(tài)變更的起點(diǎn)和終點(diǎn)，清晰展示狀態(tài)的變化過(guò)程。
• event：具體的事件名稱，如 PaymentSuccess 或 CloseOrder，明確觸發(fā)狀態(tài)變更的原因。
• operator：記錄是由誰(shuí)或哪個(gè)系統(tǒng)觸發(fā)了本次變更，方便后續(xù)的責(zé)任追溯。
• remark：可以寫入失敗原因、第三方返回碼等輔助信息，為問(wèn)題排查和分析提供更多的線索。
• create_time：記錄狀態(tài)變更的發(fā)生時(shí)間戳，便于進(jìn)行時(shí)間維度的統(tǒng)計(jì)和分析。

五、項(xiàng)目中狀態(tài)機(jī)的落地方式

5.1 手寫狀態(tài)機(jī)

在大多數(shù)項(xiàng)目中，手動(dòng)編寫狀態(tài)機(jī)映射或狀態(tài)流轉(zhuǎn)表是一種常見(jiàn)的做法。以下是具體的實(shí)現(xiàn)步驟：

首先，定義支付狀態(tài)和支付事件的枚舉類：

圖片

然后，在代碼中使用映射或 if-else / switch 邏輯來(lái)控制當(dāng)前狀態(tài)和事件到下一個(gè)狀態(tài)的轉(zhuǎn)換規(guī)則。每次更新訂單狀態(tài)時(shí)，需要按照以下步驟進(jìn)行操作：

1. 查詢訂單的當(dāng)前狀態(tài)。
2. 判斷是否允許觸發(fā)對(duì)應(yīng)的事件。
3. 如果允許，則將訂單狀態(tài)更新為目標(biāo)狀態(tài)。
4. 插入一條狀態(tài)變更記錄到 payment_status_history 表中。

以下是一個(gè)示例代碼：

圖片

5.2 使用 Spring StateMachine

Spring 提供了 Spring Statemachine 庫(kù)，該庫(kù)可以更加系統(tǒng)化地管理復(fù)雜的狀態(tài)、事件和轉(zhuǎn)移。

它支持分層狀態(tài)機(jī)、并行狀態(tài)機(jī)等高級(jí)功能，還可以配置監(jiān)聽(tīng)器在狀態(tài)變更時(shí)自動(dòng)將相關(guān)信息寫入數(shù)據(jù)庫(kù)。該庫(kù)適用于狀態(tài)過(guò)多、流程極其復(fù)雜或需要可視化管理的場(chǎng)景。

然而，如果團(tuán)隊(duì)對(duì)該框架不太熟悉，且業(yè)務(wù)需求不算特別復(fù)雜，手寫狀態(tài)機(jī)往往已經(jīng)能夠滿足需求。

關(guān)于Spring StateMachine 可以看陳某之前的文章：項(xiàng)目終于用上了Spring狀態(tài)機(jī)，非常優(yōu)雅！

六、關(guān)鍵關(guān)注點(diǎn)解析

1. 冪等性的保障

支付回調(diào)可能會(huì)多次觸發(fā)，為了確保系統(tǒng)的穩(wěn)定性和數(shù)據(jù)的準(zhǔn)確性，需要保證重復(fù)回調(diào)不會(huì)導(dǎo)致重復(fù)更新或錯(cuò)誤更新?？梢栽跀?shù)據(jù)庫(kù)層面進(jìn)行冪等校驗(yàn)，例如，如果訂單狀態(tài)已經(jīng)是 SUCCESS，再次收到成功回調(diào)時(shí)可以直接忽略該請(qǐng)求。

2. 異常場(chǎng)景的處理

• 第三方回調(diào)丟失：當(dāng)?shù)谌交卣{(diào)信息丟失時(shí)，訂單可能會(huì)一直停留在 PENDING 狀態(tài)。為了解決這個(gè)問(wèn)題，需要定期主動(dòng)查詢第三方支付結(jié)果，確保訂單狀態(tài)能夠及時(shí)更新。
• 超時(shí)關(guān)閉：如果用戶長(zhǎng)時(shí)間未支付，訂單可以自動(dòng)從 CREATED 或 PENDING 狀態(tài)轉(zhuǎn)為 CLOSED 狀態(tài)，以釋放系統(tǒng)資源，避免無(wú)效訂單的占用。
• 退款失?。喝舻谌酵丝钍?，訂單需要回到 SUCCESS 狀態(tài)，并且可以再次發(fā)起退款請(qǐng)求，確保用戶的退款需求能夠得到妥善處理。

3. 部分退款的處理

如果業(yè)務(wù)允許部分退款，需要額外記錄已退金額和剩余可退金額等信息。同時(shí)，狀態(tài)機(jī)也需要支持部分退款成功、多次退款等更復(fù)雜的場(chǎng)景，以滿足業(yè)務(wù)的多樣化需求。通過(guò)合理設(shè)計(jì)狀態(tài)機(jī)和數(shù)據(jù)庫(kù)表結(jié)構(gòu)，可以確保部分退款業(yè)務(wù)的順利進(jìn)行。

4.數(shù)據(jù)一致性

通常使用數(shù)據(jù)庫(kù)事務(wù)保證訂單表與狀態(tài)變更表的同步更新；

大規(guī)模系統(tǒng)可采用消息隊(duì)列或分布式事務(wù)方案。

5.對(duì)賬與統(tǒng)計(jì)

完整的支付系統(tǒng)還需要對(duì)賬邏輯（對(duì)比第三方交易流水），并將狀態(tài)變更表的數(shù)據(jù)用于審計(jì)與統(tǒng)計(jì)分析。

七、總結(jié)

1.狀態(tài)機(jī)設(shè)計(jì)：

列出核心狀態(tài)（CREATED、PENDING、SUCCESS、FAIL、REFUNDING、REFUNDED、CLOSED 等）和對(duì)應(yīng)事件；

明確當(dāng)前狀態(tài) + 事件 -> 下一個(gè)狀態(tài)的規(guī)則，保證每次狀態(tài)變更都有明確觸發(fā)。

2.狀態(tài)變更記錄表：

建議使用多條記錄的方式保存狀態(tài)流轉(zhuǎn)歷史，每次變更都插入一條；

表中至少包含訂單標(biāo)識(shí)、原狀態(tài)、新?tīng)顟B(tài)、觸發(fā)事件、操作人、時(shí)間、備注等核心字段；

方便后續(xù)審計(jì)、問(wèn)題排查與統(tǒng)計(jì)分析。

3.關(guān)鍵落地點(diǎn)：

確保冪等與異常場(chǎng)景處理；

考慮部分退款、多次退款等業(yè)務(wù)需求；

根據(jù)團(tuán)隊(duì)熟悉程度，選擇手寫狀態(tài)機(jī)或Spring StateMachine；

在大規(guī)模或合規(guī)要求高的場(chǎng)景中，要特別重視審計(jì)和數(shù)據(jù)一致性。

通過(guò)以上設(shè)計(jì)，一個(gè)支付系統(tǒng)就能夠在單體或微服務(wù)架構(gòu)中實(shí)現(xiàn)對(duì)訂單全生命周期的有效管理，保持狀態(tài)清晰、有序，滿足合規(guī)與審計(jì)需求，并在異常場(chǎng)景下依舊具備較好的可維護(hù)性和可追溯性。