調用交易服務更新訂單價格失敗

支付寶上有一種保險叫國民保險和終身養老金。

看它宣傳的各種保障和待遇都很好，但人們往往沉浸在表面。你可以看看下圖中我用紅線圈出的地方：增保額協議、支付授*、保險通知、產品手冊、保險條款、平臺服務協議。

有多少人認真讀過，理解過，理解過？只在表面上參加保險是個忌諱。

參加國民保險終身養老金有15天的猶豫期。在猶豫期間，我們可以全額退保，并按照我們支付的金額退款。猶豫期過后，能退多少錢需要按照相關規定執行。根據保險，是可退保單的現金價值。

保單的現金價值是多少？保單的現金價值與我們的投資理財完全不同。無論是投資理財還是存錢，我們付出的錢的本金都是屬于我們的。但是，我們交的保費不是存款和理財。保費由保險公司控制。如果買意外險，在規定期限內不會發生意外，所有保費不退。商業養老分紅保險也是如此，只是保費不會完全扣除，而是從保險公司的某些必要費用中扣除，如賬戶管理費、風險保險費、銷售渠道費或代理傭金等。產品介紹里有這樣一個演示：

30歲一次性繳納保費1萬元，60歲每年保額1010元。

一次付清保費后，退保金的現金價值，也就是保單，只有8160元。而且所有保單的現金價值都是按照3%左右的保證利率，以每年8160元的速度遞增。但是知道還有一定的浮動分紅，從0%到3%不等，無法保證，還是很欣慰的。如果回報率只有3%，我們投資理財真的不是很有吸引力。要達到4%~5%的收益率還是很簡單的。

如果許多人從這種不確定性出發，他們參與保險的意愿將大大降低。畢竟30歲的我存了一萬塊錢，60歲以后一年只拿1010塊。30年后的購買力如何？人們對此深表懷疑。所以保險的特點是長期穩定，各種利益基本可以在保險合同中約定，未來長期不變，讓保險公司通過各種金融手段實現長期目標，穩定掙錢。

與商業養老保險相比，社會養老保險有其自身的特點。社會保險由國家法律強制執行，由國家管理、征收、支付甚至補貼。為了避免養老金流于形式，國家應確保退休人員的待遇符合經濟和社會發展。所以很多國家都采用現收現付的養老保險模式，比較大的好處就是可以保證購買力的穩定。然后，國家通過各種手段形成養老保險平準基金的余額，用于調節保險基金的收支波動。2018年，全國基本養老保險基金收入51168億元，支出44645億元，養老保險基金累計余額超過5萬億元。可能以前參加保險的老人只交了一點點養老保險，視同繳費期的很多保險費都是國家交的，但是現在每個月的養老金都是三四千元，很劃算。不要以為國家出錢就沒人出錢。2017年，政*補助基本養老保險基金8004億元。2019年中央安排養老保險基金補貼5600多億元，未計入人員和場所支出。因此，中國的養老保險是一項非常虧損的業務，但它也是為了社會的福利。

說商業養老保險不劃算嗎？其實商業養老保險比較大的特點不是投資，而是穩定。如果我們的收入很不穩定，比如現在可能一年賺幾百萬，但是以后可能會失業，那就要買商業養老保險了。收入高的時候參加養老保險，是平衡未來收入現金流的一個非常有利的保障。李嘉誠給每一個孫子孫女買了1億港幣的養老分紅保險，可以保證這些孩子吃好，每個月至少有幾十萬港幣的分紅收入。至于這幾十萬元幾十年的購買力，沒必要考慮太多。

綜上所述，商業養老保險有其特定的功能。如果把它當成存款或者投資理財，其實是有偏差的理解。好了，回到的話題。就來分享一下支付系統中的一些異常處理方法。

其實這些處理方式并不局限于支付系統，也可以應用到其他系統，可以借鑒應用到自己的系統，提高自己系統的健壯性。

異常是系統運行中不可避免的問題。如果一切正常，我們的系統設計會相當簡單。

不幸的是，沒有人能做到這一點，所以為了處理異常可能帶來的問題，我們不得不增加很多額外的設計來處理這些異常。

可以說，在系統設計中，異常處理需要我們專注于思考，會占用我們大部分的精力。

讓我們先來看看支付系統中比較常見的異常：「掉單」

刪除文檔時出現異常

比較常見的支付平臺架構關系如下：

以攜程為例，在其上發起訂單支付將經過三個系統：

攜程創建訂單并向第三方支付公司發起支付請求

第三方支付公司創建訂單并向工行發起支付請求

工行完成扣款操作，返回第三方支付公司

第三方支付完成訂單更新，返回攜程

攜程更改訂單狀態

上述過程很簡單，如下圖所示：

在這個過程中，可能會發生用戶的工銀卡已經被借記，但攜程訂單仍未支付的情況。我們通常稱這種情況為「掉單」.

上述大多數訂單丟失的情況都是由「、」,(我們稱之為「外部掉單」.)的信息丟失造成的

還有一種罕見的情況是，從「、」鏈接返回的信息被接收，但是系統未能更新「、」鏈接中的訂單狀態，這導致成功支付信息的丟失。因為這種訂單取消是內部問題，我們通常稱之為「內部掉單」.

外部掉單

外部取消是因為沒有收到對端返回的信息。這種情況很可能是網絡問題，或者是對端處理邏輯太慢，導致我們的請求超時，直接斷開網絡請求。

增加超時時間

對于這種情況，第一個比較簡單的解決方案是「適當的增加超時時間」.

但是這里需要注意的是，我們增加網絡超時后，可能需要調整整個鏈路的超時，否則可能會導致整個鏈路的內部跑腿，導致內部賬單丟失。

第二種方法是接收通道異步接收通知信息。

一般來說，我們現在可以向支付渠道接口發送一個異步回調地址，當渠道端處理成功時，會通知回調地址成功的信息。

在這種情況下，我們只需要接收通知信息，進行分析，然后更新內部訂單狀態。

支付系統異常處理-支付異步通知

在這種情況下，我們需要注意幾點：

對于異步請求信息，需要對通知內容進行簽名和驗證，并檢查返回的訂單金額是否與商戶方的訂單金額一致，以防止因數據泄露而導致的“誤通知”，造成資金損失。

異步通知會發送很多次，所以異步通知處理需要冪等性。

掉單查詢

有些渠道可能不提供異步通知功能，只提供訂單查詢的接口。在這種情況下，我們只能使用第三種解決方案，即定期下訂單進行查詢。

我們可以將這種未知超時的訂單單獨保存到訂單投放表中，然后從渠道端定期查詢訂單的狀態。

如果查詢成功或失敗(例如，訂單不存在，等等。)，可以更新訂單狀態，刪除單表記錄。

如果查詢仍然未知，那么我們需要等待下一次查詢的結果。

調用交易服務未能更新訂單價格(如何手動檢查快遞停運區域)" src=" https://p6-tt.byteimg.com/origin/pgc-image/c6ffadf 52e 64497 ba 953 ac 0704677356 . jpg " data-origin=" https://p6-tt . byteimg.com/origin/pgc-image/c6ffadf 52e 64497 ba 953 ac 0704677356 . jpg "

支付系統異常處理-定期查詢

我們需要注意這里。在某些情況下，可能不會查詢返回訂單的狀態，因此我們需要設置訂單查詢的比較大數量，以防止無限查詢浪費性能。

對賬

比較后，在極少數情況下，訂單查詢和異步通知都不能獲得付款結果，這就剩下比較后一個解決方案，對賬。

如果第二天在渠道提供的對賬文件中發現此支付結果，我們可以根據此記錄更新直接更新我們的內部支付記錄。

之前小黑寫過一篇和解的文章。有興趣可以再看看：談談對賬系統的設計

那么，如果第二天沒有這個記錄的結果，在這種情況下，我們可以認為這是一個失敗。如果用戶被扣除，渠道將發起退款，并將支付的金額返還給用戶。因此，這種情況可能不需要處理。

內部掉單異常

支付公司內部訂單關系

接下來，我們來談談內部文檔丟棄的例外情況。首先，讓我們看看為什么會出現內部文檔刪除的異常，這實際上與我們的系統架構有關。

如上圖所示，第三方支付公司的內部表，支付訂單和渠道訂單通常是一對n的關系。

支付訂單持有外部商戶系統的訂單編號，代表第三方支付公司的內部訂單與外部商戶的訂單之間的關系。

渠道訂單代表第三方支付公司與外部渠道的關系。其實對于外部渠道系統，第三方支付公司是外部商家。

為什么需要設計這種關系？而不是用下面的一對一關系？

如果我們使用上面圖1-1所示的訂單關系，如果第一次支付失敗，外部商戶可能會使用相同的訂單號再次向第三方支付公司發起支付。

此時，如果第三方支付公司也以相同的內部訂單請求外部渠道系統，則有可能是外部渠道系統不支持相同的訂單號再次請求。

其實我們也有其他的方法，比如生成一個新的內部訂單號，更新原付款單上的內部記錄，然后請求外部渠道系統。但是，如果發生這種情況，比較后一次支付失敗的記錄就會丟失，不利于我們事后做一些統計。

事實上，第三方支付公司可能不支持相同的訂單號再次發起請求，但在這種情況下，外部商家需要重新生成一個新的訂單號。

在這種情況下，第三方支付公司的系統很簡單，所有的復雜性都交給了外部商家。

但是現實中很多外部商家并不是那么容易更換和生成新的訂單號的，所以一般第三方支付公司都需要支持同一個外部商家的訂單號，如果不成功就需要重復支付。

在這種情況下，我們需要上面1:n的順序圖。

內部掉單異常的原因

當我們收到來自外部渠道系統的成功返回消息時，我們成功地更新了渠道訂單的記錄。但是，由于渠道訂單表和支付訂單表可能不是同一個數據庫，所以可能不在同一個應用程序中，這可能會導致支付訂單表更新失敗。

因為支付訂單表保存了外部商戶訂單和內部訂單的關系，所以支付訂單不成功，外部商戶無法查詢得到成功的支付結果。

此時渠道訂單表已經成功，所以上述外部取消訂單的方法不適用于內部取消訂單。

內部掉單異常解決辦法

「第一種解決辦法，分布式事務。」

內部掉單異常，說白了就是因為使用數據庫交易無法同時更新支付訂單表和渠道訂單表成功或者失敗。

在這種情況下，我們實際上需要使用分布式事務。

然而，我們沒有采用這種分布式事務。第一，我們之前開發的時候市場上還沒有開源的成熟的分布式事務框架。第二，自己開發非常困難。

因此，沒有使用分布式事務的經驗。如果有學生用分布式事務解決這類問題，留言評論。

「第二種解決辦法，異步補償更新。」

如果發生內部單據丟失，即無法更新付款單，可以將此處的付款單保存到內部單據丟失表中。

但是，這里可能有問題，我們不能保證保存到內部下拉列表的步驟會成功。

所以我們還需要定期查詢，在渠道訂單表中查詢一段時間內已成功支付的付款訂單記錄，然后插入內部降單表中。

在另一個系統應用中，只需要定期掃描內部掉單表，支付訂單成功，然后刪除內部掉單記錄即可。

這里需要注意的是，當支付訂單表中的數據量較大時，常規查詢可能會比較慢。為了防止主倉庫受到影響，這種查詢可以在備用倉庫中進行。

總結

我們主要介紹支付系統中的掉單例外，這種情況往往會導致用戶實際上已經被扣了錢，但是商家訂單還在等待支付的情況。

如果這個異常處理不好，會導致用戶體驗差，可能會收到客戶的投訴。

丟單的例外通常可以是外部系統，也可以是內部系統。大部分訂單的下降是由外部系統造成的。我們可以增加超時，查詢掉的訂單，接受異步通知，解決99%的問題。剩下的1%的訂單只能通過第二天的對賬來彌補。

內部系統導致訂單丟失異常是分布式環境下數據一致性的典型問題。對于這類問題，我們不需要追求強一致性，只要保證比較終的一致性即可。我們可以使用分布式事務來解決這樣的問題，或者我們可以定期掃描狀態不一致的訂單，然后批量更新。

比較后，這一次我們只介紹支付系統中的一種異常掉單。在下一篇文章中，我們將介紹支付系統的其他異常情況，敬請期待！