資料一致性（一）

mysql的事務是資料一致性的典範，事務內的執行要麼都成功，要麼都失敗。但業務系統涉及系統間的相互呼叫，涉及的資料庫也不盡相同，所以實現資料一致性還是有挑戰的。

首先了解強一致性和弱一致性。在微服務中，系統間通過http的方式相互呼叫，很難實現資料的強一致。我們這裡主要說弱一致性，也就是資料最終一致性。

資料一致性還有個重要的前提：支援冪等。也就是說，只要請求引數不變，那麼無論重複請求多少次，結果都一樣。在對接第三方支付時，這個詞出現的頻率還是老高的。

蝸牛要在一家電商**買電子書，整個購買流程和涉及的系統虛構如下圖。過程涉及檢查它是否已經買過，然後是生成訂單號、支付、交付（實際上訂單系統不包含支付功能，這裡簡化處理）。

交付涉及三個系統，在任何乙個系統內，資料庫的事務都只能保證它服務內的資料一致。而且，如果在事務過程中引入了呼叫第三方的http請求，資料庫的事務執行結果甚至有可能會被汙染。比如，http請求超時返回失敗，但實際上請求卻執行成功的場景。

參考之前寫的 saga pattern模式，對任何乙個外部服務的呼叫都引入兩個行為：執行和補償。補償是對執行結果的修正。比如對於使用者支付失敗的場景，補償行為可以是介面重試、可以是直接退款、還可以推送mq非同步修復等。

統一使用inte***ce來定義一套規範。每一種支付方式以及購買產品所呼叫的外部服務可能不盡相同，用inte***ce來達到統一呼叫的目的。補償的行為都基於執行動作返回的錯誤，所以我們需要實現自己的錯誤碼。

type deliverpattern inte***ce

對於如何補償，不同的業務有不同的補償方式，當讓不能一概而論。但整體的思想，我覺得還是不外乎兩種。當然，下面的兩種描述是自己這樣稱呼的。

事務類

首先便是資料庫事務類，任何乙個流程失敗，整個事務內的操作全部反向回滾。沿著這樣的思路，介面定義中paycompensate應該實現dopay的回滾操作，而delivercompensate應該實現dopay以及dodeliver的回滾操作。

我們需要在操作的同時維護乙個回滾操作的佇列，任何乙個do行為的完成，都需要在回滾佇列中插入對應的回滾方法。當後面任何乙個do操作失敗，統一執行回滾佇列的方法。

這樣的困境在於你不能完全保證回滾方法一定成功執行。而且出於效能考慮，還需要結合非同步佇列，通過後台重試來保證整個業務流程徹底回滾成功或回滾失敗。

狀態類

每個業務都會拆分成各個更小的塊，就跟寫**空行一樣，這裡的deliverpattern也是根據業務流程拆分成更小的執行粒度。我們可以為每個do行為都設定乙個狀態碼，類似於狀態機，記錄每一次購買的各個狀態。

const (
statusdopaysuccess           = 1
statusdopaycompensatesuccess = 2
statusdopaycompensatefailure = 3
)

這樣我們補償方法中執行的不再是回滾操作，而是do方法的重試。如果補償成功，繼續執行後續的操作，如果補償失敗，記錄下該狀態，後續看看怎麼補償。