資料一致性（一）

摘要： MySQL 的事務是資料一致性的典範，事務內的執行要麼都成功，要麼都失敗。但業務系統涉及系統間的相互呼叫，涉及的資料庫也不盡相同，所以實現資料一致性還是有挑戰的。 首先了解強一致性和弱一致性。在微服務中，系統間通過HTTP 的方式相互呼叫，很難實現資料的強一致。我們...

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

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

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

購買業務

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

<center>

</center>

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

程式碼設計

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

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

type DeliverPattern interface {
//是否需要執行交付流程
Check(ctx *context.Context) (bool, error)

//支付及支付補償
DoPay(ctx *context.Context) error
PayCompensate(ctx *context.Context, doErr error) error

//交付及對應的補償
DoDeliver(ctx *context.Context)
DeliverCompensate(ctx *context.Context, doErr error) error
}

如何補償

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

事務類

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

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

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

狀態類

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

const (
StatusDoPaySuccess= 1
StatusDoPayCompensateSuccess = 2
StatusDoPayCompensateFailure = 3
)

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