談談對2pc和3pc一致性算法的理解

自我總結，表達的不太清楚。若是須要了解的朋友請直接閱讀參考http://www.hollischuang.com/archives/681#rd?sukey=3997c0719f1515205acb269da14295ad50b0186483fbd0a402a566f45b33525978b375ccc44dba3e85c4d645a320ba47

單機事務

---

何爲事務？是指做爲單個邏輯工做單元執行的一系列操做，要麼徹底地執行，要麼徹底地不執行。一個事務須要知足ACID即原子性、一致性、隔離性、持久性。

分佈式事務

---

在單機狀況下事務很容易知足，若是一個邏輯工做單元執行的一系列操做跨越了多臺機器如何處理，多臺機器相互之間又怎麼知道對方成功了仍是失敗了。解決分佈式事務的關鍵就是必須有一種方法可以知道事務在任何地方所作的任何動做，提交或者回滾的決定必須產生統一的結果。

XA規範

---

Open Group定義了一套DTP分佈式模型，主要含有AP（應用程序）,TM（事務管理器）,RM（資源管理器）,CRM（通信資源管理器）四部分。常規下RM通常指的就是數據庫，CRM主要有各類各樣的消息中間件來實現。

XA則是DTP模型定義TM和RM以前通信的接口規範。XA接口函數由數據庫廠商提供。TM交易中間件用它來通知數據庫事務的開始、結束以及提交、回滾等。

二階段提交和三階段提交就是根據這種思想衍生而來。

2pc & 3pc

---

2pc

主要分兩兩個階段

第一階段：協調者詢問參與者是否能夠提交事務。若是參與者事務操做執行成功則回覆yes,反之no

第二階段：參與者都回復yes,協調者發出提交請求，則參與者收到後開始提交事務並釋放相關資源。反之參與者則事務回滾並釋放資源

可能出現的問題

第二階段的時候，假如其中一個參與者收到了do commit命令而後它提交了事務，可是另一個參與者可能由於網絡問題或者協調者掛掉了，致使一直苦苦等待一直佔用資源，另外致使數據不一致

另外假如協調者是集羣，若是協調者在發出一個commit指令的時候宕機了，而後恰好一個接受到該命令的參與者也宕機了，等選舉出新的協調者的時候，沒法知道如今事務的狀態

3pc

主要分三個階段

第一階段協調者詢問參與者是否能夠執行事務，參與者就分析自身是否可以成功執行事務操做，能夠則返回yes,不然no

第二階段參與者收到後則開始執行事務操做，執行成功後反饋yes給協調者反之no

第三階段協調者根據參與者的反饋選擇發起abort或者commit命令

改進點

增長了超時機制

第二階段，若是協調者超時沒有接受到參與者的反饋，則自動認爲失敗，發送abort命令

第三階段，若是參與者超時沒有接受到協調者的反饋，則自動認爲成功開始提交事務（基於機率）

2PC與3PC的區別

相對於2PC，3PC主要解決的單點故障問題，並減小阻塞，由於一旦參與者沒法及時收到來自協調者的信息以後，他會默認執行commit。而不會一直持有事務資源並處於阻塞狀態。可是這種機制也會致使數據一致性問題，由於，因爲網絡緣由，協調者發送的abort響應沒有及時被參與者接收到，那麼參與者在等待超時以後執行了commit操做。這樣就和其餘接到abort命令並執行回滾的參與者之間存在數據不一致的狀況。