前言
前面介紹了傳統單庫，單服務通過數據庫的ACID模式來解決事務的一致性，但是隨着數據量的變大，採用了分庫策略。或者服務架構逐漸演變爲微服務或者其他分佈式架構。這時候ACID也只能鞭長莫及了。這裏來和大家一起學習下應對這種問題強一致性解決方案。
二階段提交協議
在分佈式系統中，每個數據庫只能保證自己的數據可以滿足 ACID 保證強一致性，但是它們可能部署在不同的服務器上，只能通過網絡進行通信，因此無法準確的知道其他數據庫中的事務執行情況。因此，爲了解決多個節點之間的協調問題，就需要引入一個協調者負責控制所有節點的操作結果，要麼全部成功，要麼全部失敗。其中，XA 協議是一個分佈式事務協議，它有兩個角色：事務管理者和資源管理者。這裏，我們可以把事務管理者理解爲協調者，而資源管理者理解爲參與者。
二階段提交協議，顧名思義，它具有兩個階段：第一階段準備，第二階段提交。這裏，事務管理者（協調者）主要負責控制所有節點的操作結果，包括準備流程和提交流程。第一階段，事務管理者（協調者）向資源管理者（參與者）發起準備指令，詢問資源管理者（參與者）預提交是否成功。如果資源管理者（參與者）可以完成，就會執行操作，並不提交，最後給出自己響應結果，是預提交成功還是預提交失敗。第二階段，如果全部資源管理者（參與者）都回復預提交成功，資源管理者（參與者）正式提交命令。如果其中有一個資源管理者（參與者）回覆預提交失敗，則事務管理者（協調者）向所有的資源管理者（參與者）發起回滾命令。舉個案例，現在我們有一個事務管理者（協調者），三個資源管理者（參與者），那麼這個事務中我們需要保證這三個參與者在事務過程中的數據的強一致性。首先，事務管理者（協調者）發起準備指令預判它們是否已經預提交成功了，如果全部回覆預提交成功，那麼事務管理者（協調者）正式發起提交命令執行數據的變更。
注意的是，雖然二階段提交協議爲保證強一致性提出了一套解決方案，但是仍然存在一些問題。其一，事務管理者（協調者）主要負責控制所有節點的操作結果，包括準備流程和提交流程，但是整個流程是同步的，所以事務管理者（協調者）必須等待每一個資源管理者（參與者）返回操作結果後才能進行下一步操作。這樣就非常容易造成同步阻塞問題。其二，單點故障也是需要認真考慮的問題。事務管理者（協調者）和資源管理者（參與者）都可能出現宕機，如果資源管理者（參與者）出現故障則無法響應而一直等待，事務管理者（協調者）出現故障則事務流程就失去了控制者，換句話說，就是整個流程會一直阻塞，甚至極端的情況下，一部分資源管理者（參與者）數據執行提交，一部分沒有執行提交，也會出現數據不一致性。此時，讀者會提出疑問：這些問題應該都是小概率情況，一般是不會產生的？是的，但是對於分佈式事務場景，我們不僅僅需要考慮正常邏輯流程，還需要關注小概率的異常場景，如果我們對異常場景缺乏處理方案，可能就會出現數據的不一致性，那麼後期靠人工干預處理，會是一個成本非常大的任務，此外，對於交易的核心鏈路也許就不是數據問題，而是更加嚴重的資損問題。
三階段提交協議
二階段提交協議諸多問題，因此三階段提交協議就要登上舞臺了。三階段提交協議是二階段提交協議的改良版本，它與二階段提交協議不同之處在於，引入了超時機制解決同步阻塞問題，此外加入了預備階段儘可能提早發現無法執行的資源管理者（參與者）並且終止事務，如果全部資源管理者（參與者）都可以完成，才發起第二階段的準備和第三階段的提交。否則，其中任何一個資源管理者（參與者）回覆執行，或者超時等待，那麼就終止事務。總結一下，三階段提交協議包括：第一階段預備，第二階段準備，第二階段提交。
三階段提交協議很好的解決了二階段提交協議帶來的問題，是一個非常有參考意義的解決方案。但是，極小概率的場景下可能會出現數據的不一致性。因爲三階段提交協議引入了超時機制，如果出現資源管理者（參與者）超時場景會默認提交成功，但是如果其沒有成功執行，或者其他資源管理者（參與者）出現回滾，那麼就會出現數據的不一致性。