分析簡化分佈式支付系統的存在的數據丟失問題

    由於公司自己的支付系統比較複雜，我這邊刪減掉了一大部分功能，主要針對回調通知這塊業務來作分佈式事物的說明，這塊業務也是全部支付業務裏面最重要的業務，對數據一致性要求最高的一塊業務。下面咱們來看簡化後的第三方支付系統的系統架構圖。

說明：

  3rd-access能夠理解成一個支付網管,全部支付請求和支付結果回調都經過它進行分發。

途中每個小各自表明一個獨立的系統，整個架構採用微服務的形式。

整個請求的流程在圖中已經畫的很明顯，在此不作特殊的說明。咱們要作的是來分析，每一步的流程，或者服務的宕機形成的數據丟失問題。

1：發起支付，若是這步由於3rd-access或者網絡緣由，不能進行，那麼全部用戶都不能進行付費，雖然支付系統掛了，可是數據目前來講仍是一致的，只是都是失敗而已。

2：建立支付訂單，若是這步由於訂單服務宕機或者網絡緣由引發用戶不能下單，那麼同上。

3：選擇支付方式，若是這步由於支付插件宕機形成取不到對應的支付方式，可是如今訂單庫已經有訂單了，只是訂單的狀態目前仍是「支付中」，並無支付成功，在程序上其實默認仍是默認失敗的，因此只是整個支付失敗而已，並不會形成支付數據的丟失。

4：支付回調，這步咱們不可控暫時先忽略。下面的分析，都默認支付結果都正常回調

5：更新狀態，當好比支付寶已經付款成功(錢已經扣了)，支付寶也成功將訂單的支付結果回調到咱們的支付網關了(3rd-access)。若是在更新訂單的時候，由於訂單系統宕機了，那麼原本應該更新支付訂單的狀態爲"支付成功"的，如今由於服務掛了，訂單表該筆訂單仍是「支付處理中」的狀態，那麼至關於用戶的錢白扣了，因此step5會形成支付數據的丟失，致使數據不一致的問題。

6：通知商戶支付結果，假設第5步是更新成功的，數據的訂單狀態爲"支付成功"。可是在通知商戶的時候，由於商戶的服務掛了或者網絡有問題，那麼該通知就不能成功通知到商戶（用戶），致使扣取了用戶的錢，可是沒有下發對應的權益。因此step6也會形成支付數據的丟失,致使數據不一致的問題。

7：通知"積分","營帳","充值"系統，這個跟通知商戶類型，只是這個是經過接口異步通知的，另外一個是經過http的方式進行通知的。這部分也會形成明明訂單是成功的，訂單狀態已是「支付成功」，可是對應的積分沒加，對應對帳系統也沒加，致使後期訂單庫與其餘系統數據對不上，形成髒數據的問題。

數據的一致性，服務的高可用是支付系統的核心，由於分分鐘都是錢啊。

下面標紅的地方就是可能發生數據丟失的地方，咱們再來看一邊。

這些服務都是分佈式獨立部署的，有的甚至是多節點部署，很顯然利用傳統的本地事物是處理不了的。

那麼如何設計分佈式事物的方案，解決數據不一致的問題呢？不要急下面的文章會爲你們解答。

/** *   ————————若是以爲本博文還行，別忘了推薦一下哦，謝謝！ *   做者：寫程序的奧特曼 *   歡迎轉載，請保留此段聲明。 *   出處：https://my.oschina.net/u/2286631/blog/1504582 */