分佈式事務解決方案----最大努力通知解決方案

     在介紹方案以前，我帶着你們回顧一下以前我簡化完的支付系統，以及支付系統中出現的分佈式事務的問題。

在3rd-access成功更新訂單，可是通知商戶由於網絡或者商戶服務宕機的緣由，沒有通知成功step6,這時候會帶來訂單數據的丟失，致使商戶那邊明明釦了錢，可是得不到不到權益，下面咱們就針對這種狀況，一塊兒探討下解決方案。

 

爲了更好的探討這個問題，咱們將系統的其餘服務暫時先拋棄，針對step6進行一個分析。如圖

針對step6,一般咱們會用一個http請求的方式去通知商戶。可是http是無狀態協議，通知一次失敗了就失敗了，因此咱們在想是否可以作成重複通知的狀況，若是沒有通知就每隔多少時間再通知一次。可是又不是無限的通知下去，一次又一個最大的通知次數。可是，若是這個數據很重要，在到達最大通知次數以後咱們再也不通知了，可是商戶如今又修復好了服務，讓我從新通知一次，那咱們又該如何處理那，下面來看改造以後的方案。如圖：

紅線部分是老的通知方案，其餘最大努力通知的方案。

1. 支付寶支付回調成功結果
2. 3rd-access(更新訂單，並把結果丟到消息服務Mq),這兩步在同一個本地事務中進行，保證了一致性。
3. 通知服務能夠成一個監聽服務，監聽到mq裏面有新的消息，立刻取出來(狀態爲"消費中")保存到通知庫，而且通知商戶，這個過程也在本地事務進行，保證數據的一致性
4. 商戶響應接收成功，通知服務會刪除mq裏面的消息(更改消息爲"消費成功")

這樣保證了正向流程的消息一致性。

那麼針對異常流程，是否會形成消息的丟失呢？咱們來看下狀況

1.     在此咱們默認訂單是更新成功的(這裏會在第二套方案裏面講)，由於消息服務是高可用架構，因此宕機的可能性不大，並且更新訂單和丟數據到mq是同一個事物，要麼所有成功，要麼所有失敗，因此訂單更新成功的，該消息必定成功的丟到了mq裏面，而且爲了保證數據一致性，該消息是必定要被消費並且通知給商戶的。
2.    若是通知服務有問題，那麼消息只是沒有被消費而已，仍是一直存在消息服務裏面的，因此一旦通知服務恢復正常，消息仍是能被消費的，這裏並不會致使消息的丟失。
3. 通知消息入庫有問題，那麼這裏會拋出異常，可是由於只有真正通知成功mq裏面的消息纔會被真正消息，若是這裏拋異常，那麼mq裏面的消息至關於沒有成功被消息，下次依然會進行入庫，通知操做。
4. http通知商戶有問題，那麼通知服務會每隔1,5,10,30分鐘重複通知。若是達到最大通知次數依然沒有通知成功，那麼後續的數據仍是保存在通知庫裏面，經過cmp進行管理，後續商戶有通知需求的時候，經過人工的操做cmp,從新重置通知次數，這樣消息又能夠從新通知了，達到了最大努力通知的一個方案。

具體的方案協議細節以下圖：

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