介紹
在分布式系統、微服務架構大行其道的今天，服務間互相調用出現失敗已經成為常态。如何處理異常，如何保證資料一緻性，成為微服務設計過程中，繞不開的一個難題。 在不同的業務場景下，解決方案會有所差異，常見的方式有：
阻塞式重試；
2PC、3PC 傳統事務；
使用隊列，背景異步處理；
TCC 補償事務；
本地消息表（異步確定）；
MQ 事務。
本文側重于其他幾項，關于 2PC、3PC 傳統事務，網上資料已經非常多了，這裡不多做重複。
阻塞式重試
在微服務架構中，阻塞式重試是比較常見的一種方式。僞代碼示例：
m := db.Insert(sql)
err := request(B-Service,m)
func request(url string,body interface{}){
for i:=0; i<3; i ++ {
result, err = request.POST(url,body)
if err == nil {
break
}else {
log.Print()
}
}
} 如上，當請求 B 服務的 API 失敗後，發起最多三次重試。如果三次還是失敗，就列印日志，繼續執行下或向上層抛出錯誤。這種方式會帶來以下問題
調用 B 服務成功，但由于網絡逾時原因，目前服務認為其失敗了，繼續重試，這樣 B 服務會産生 2 條一樣的資料。
調用 B 服務失敗，由于 B 服務不可用，重試 3 次依然失敗，目前服務在前面代碼中插入到 DB 的一條記錄，就變成了髒資料。
重試會增加上遊對本次調用的延遲，如果下遊負載較大，重試會放大下遊服務的壓力。
第一個問題：通過讓 B 服務的 API 支援幂等性來解決。
第二個問題：可以通過背景定時腳步去修正資料，但這并不是一個很好的辦法。
第三個問題：這是通過阻塞式重試提高一緻性、可用性，必不可少的犧牲。
阻塞式重試适用于業務對一緻性要求不敏感的場景下。如果對資料一緻性有要求的話，就必須要引入額外的機制來解決。
異步隊列
在解決方案演化的過程中，引入隊列是個比較常見也較好的方式。如下示例：
m := db.Insert(sql)
err := mq.Publish("B-Service-topic",m)
在目前服務将資料寫入 DB 後，推送一條消息給 MQ，由獨立的服務去消費 MQ 處理業務邏輯。和阻塞式重試相比，雖然 MQ 在穩定性上遠高于普通的業務服務，但在推送消息到 MQ 中的調用，還是會有失敗的可能性，比如網絡問題、目前服務當機等。這樣還是會遇到阻塞式重試相同的問題，即 DB 寫入成功了，但推送失敗了。
理論上來講，分布式系統下，涉及多個服務調用的代碼都存在這樣的情況，在長期運作中，調用失敗的情況一定會出現。這也是分布式系統設計的難點之一。
TCC 補償事務
在對事務有要求，且不友善解耦的情況下，TCC 補償式事務是個較好的選擇。
TCC 把調用每個服務都分成 2 個階段、 3 個操作：
階段一、Try 操作：對業務資源做檢測、資源預留，比如對庫存的檢查、預扣。
階段二、Confirm 操作：送出确認 Try 操作的資源預留。比如把庫存預扣更新為扣除。
階段二、Cancel 操作：Try 操作失敗後，釋放其預扣的資源。比如把庫存預扣的加回去。
TCC 要求每個服務都實作上面 3 個操作的 API，服務接入 TCC 事務前一次調用就完成的操作，現在需要分 2 階段完成、三次操作來完成。
比如一個商城應用需要調用 A 庫存服務、B 金額服務、C 積分服務，如下僞代碼：
m := db.Insert(sql)
aResult, aErr := A.Try(m)
bResult, bErr := B.Try(m)
cResult, cErr := C.Try(m)
if cErr != nil {
A.Cancel()
B.Cancel()
C.Cancel()
} else {
A.Confirm()
B.Confirm()
C.Confirm()
} 代碼中分别調用 A、B、C 服務 API 檢查并保留資源，都傳回成功了再送出确認（Confirm）操作；如果 C 服務 Try 操作失敗後，則分别調用 A、B、C 的 Cancel API 釋放其保留的資源。
TCC 在業務上解決了分布式系統下，跨多個服務、跨多個資料庫的資料一緻性問題。但 TCC 方式依然存在一些問題，實際使用中需要注意，包括上面章節提到的調用失敗的情況。
空釋放
上面代碼中如果 C.Try() 是真正調用失敗，那下面多餘的 C.Cancel() 調用會出現釋放并沒有鎖定資源的行為。這是因為目前服務無法判斷調用失敗是不是真的鎖定 C 資源了。如果不調用，實際上成功了，但由于網絡原因傳回失敗了，這會導緻 C 的資源被鎖定，一直得不到釋放。
空釋放在生産環境經常出現，服務在實作 TCC 事務 API 時，應支援空釋放的執行。
時序
上面代碼中如果 C.Try() 失敗，接着調用 C.Cancel() 操作。因為網絡原因，有可能會出現 C.Cancel() 請求會先到 C 服務，C.Try() 請求後到，這會導緻空釋放問題，同時引起 C 的資源被鎖定，一直得不到釋放。
是以 C 服務應拒絕釋放資源之後的 Try() 操作。具體實作上，可以用唯一事務ID來區分第一次 Try() 還是釋放後的 Try()。
調用失敗
Cancel 、Confirm 在調用過程中，還是會存在失敗的情況，比如常見的網絡原因。
Cancel() 或 Confirm() 操作失敗都會導緻資源被鎖定，一直得不到釋放。這種情況常見解決方案有：
阻塞式重試。但有同樣的問題，比如當機、一直失敗的情況。
寫入日志、隊列，然後有單獨的異步服務自動或人工介入處理。但一樣會有問題，寫日志或隊列時，會存在失敗的情況。
理論上來講非原子性、事務性的二段代碼，都會存在中間态，有中間态就會有失敗的可能性。
本地消息表
本地消息表最初是 ebay 提出的，它讓本地消息表與業務資料表處于同一個資料庫中，這樣就能利用本地事務來滿足事務特性。
具體做法是在本地事務中插入業務資料時，也插入一條消息資料。然後在做後續操作，如果其他操作成功，則删除該消息；如果失敗則不删除，異步監聽這個消息，不斷重試。
本地消息表是一個很好的思路，可以有多種使用方式：
配合MQ
示例僞代碼：
messageTx := tc.NewTransaction("order")
messageTxSql := tx.TryPlan("content")
m,err := db.InsertTx(sql,messageTxSql)
if err!=nil {
return err
}
aErr := mq.Publish("B-Service-topic",m)
if aErr!=nil { // 推送到 MQ 失敗
messageTx.Confirm() // 更新消息的狀态為 confirm
}else {
messageTx.Cancel() // 删除消息
}
// 異步處理 confirm 的消息，繼續推送
func OnMessage(task *Task){
err := mq.Publish("B-Service-topic", task.Value())
if err==nil {
messageTx.Cancel()
}
} 上面代碼中其 messageTxSql 是插入本地消息表的一段 SQL ：
insert into `tcc_async_task` (`uid`,`name`,`value`,`status`)
values ('?','?','?','?')
1
它和業務 SQL 在同一個事務中去執行，要麼成功，要麼失敗。
成功則推送到隊列，推送成功，則調用 messageTx.Cancel() 删除本地消息；推送失敗則标記消息為 confirm。本地消息表中 status 有 2 種狀态 try、confirm， 無論哪種狀态在 OnMessage 都可以監聽到，進而發起重試。
本地事務保障消息和業務一定會寫入資料庫，此後的執行無論當機還是網絡推送失敗，異步監聽都可以進行後續處理，進而保障了消息一定會推到 MQ。
而 MQ 則保障一定會到達消費者服務中，利用 MQ 的 QOS 政策，消費者服務一定能處理，或繼續投遞到下一個業務隊列中，進而保障了事務的完整性。
配合服務調用
在 Try 處理函數中，還要單獨判斷目前消息任務是否存在過短，因為 Try狀态的消息，可能才剛剛建立，還沒被确認送出或删除。這會和正常業務邏輯的執行重複，意味着成功的調用，也會被重試；為盡量避免這種情況，可以檢測消息的建立時間是否很短，短的話可以跳過。
重試機制必然依賴下遊 API 在業務邏輯上的幂等性，雖然不處理也可行，但設計上還是要盡量避免幹擾正常的請求。
獨立消息服務
獨立消息服務是本地消息表的更新版，把本地消息表抽離成一個獨立的服務。所有操作之前先在消息服務添加個消息，後續操作成功則删除消息，失敗則送出确認消息。
然後用異步邏輯去監聽消息，做對應的處理，和本地消息表的處理邏輯基本一緻。但由于向消息服務添加消息，無法和本地操作放到一個事務裡，是以會存在添加消息成功，後續失敗，則此時的消息就是個無用消息。
如下示例場景：
這個無用的消息，需要消息服務去确認這個消息是否執行成功，沒有則删除，有繼續執行後續邏輯。相比本地事務表 try 和 confirm ，消息服務在前面多了一種狀态 prepare。
MQ 事務
有些 MQ 的實作支援事務，比如 RocketMQ 。MQ 的事務可以看作獨立消息服務的一種具體實作，邏輯完全一緻。
所有操作之前先在 MQ 投遞個消息，後續操作成功則 Confirm 确認送出消息，失敗則Cancel删除消息。MQ 事務也會存在 prepare狀态，需要 MQ 的消費處理邏輯來确認業務是否成功。
總結
從分布式系統實踐中來看，要保障資料一緻性的場景，必然要引入額外的機制處理。
TCC 的優點是作用于業務服務層，不依賴某個具體資料庫、不與具體架構耦合、資源鎖的粒度比較靈活，非常适用于微服務場景下。缺點是每個服務都要實作 3 個 API，對于業務侵入和改動較大，要處理各種失敗異常。開發者很難完整處理各種情況，找個成熟的架構可以大大降低成本，比如阿裡的 Fescar。
本地消息表的優點是簡單、不依賴其他服務的改造、可以很好的配合服務調用和 MQ 一起使用，在大多業務場景下都比較實用。缺點是本地資料庫多了消息表，和業務表耦合在一起。文中本地消息表方式的示例，來源于作者寫的一個庫，有興趣的同學可以參考下
https://github.com/mushroomsir/tccMQ 事務和獨立消息服務的優點是抽離出一個公共的服務來解決事務問題，避免每個服務都有消息表和服務耦合在一起，增加服務自身的處理複雜性。缺點是支援事務的 MQ 很少；且每次操作前都先調用 API 添加個消息，會增加整體調用的延遲，在絕大多數正常響應的業務場景下，是一種多餘的開銷。
TCC 參考：
https://www.sofastack.tech/blog/seata-tcc-theory-design-realization/MQ 事務參考：
https://www.jianshu.com/p/eb571e4065ec