從PAXOS到ZOOKEEPER分散式一致性原理與實踐--2PC(Two-Phase Commit)
2PC,是Two-Phase Commit的縮寫,即二階段提交,是計算機網路尤其是在資料庫領域內,為了使基於分散式系統架構下的所有節點在進行事務處理過程中保持原子性和一致性而設計的一種演算法。通常,二階段提交協議也被認為是一種一致性協議,用來保證分散式系統資料的一致性。目前,絕大部分的關係型資料庫都是採用二階段提交協議來完成分散式事務的提交或回滾,從而能夠有效地保證分散式資料一致性,因此二階段提交協議被廣泛應用在許多分散式系統中。
階段一:提交事務請求
1.事務詢問。
協調者向所有參與者傳送事務內容,詢問是否可以執行事務提交操作,並開始等待各參與者的響應。
2.執行事務
各參與者節點執行事務操作,並將Undo和Redo資訊記入事務日誌中。
3.各參與者向協調者反饋事務諮詢的響應。
如果參與者成功執行了事務操作,那麼就反饋給協調者Yes響應,表示事務可以執行;如果參與者沒有成功執行事務,那麼就反饋給協調者No響應,表示事務不可以執行
由於上面個講述的內容在形式上近似是協調者㢟各參與者對一次事務操作的投票表態過程,因此二階段提交協議的階段一也被成為“投票階段”,即各參與者投票是表明是否要急需執行接下去的事務提交操作
階段二:執行事務提交
在階段二中協調者會根據各參與者的反饋來決定是否最終可以進行事務提交操作,正常情況下包含兩種可能:
執行事務提交
1.傳送提交請求。
協調者向所有參與者節點發出commit請求。
2.事務提交。
參與者接收到commit請求後,會正事執行事務提交操作,並在完成提交後釋放在整個事務執行期間佔用的事務資源
3.反饋事務提交結果。
參與者在完成事務提交之後,向協調者傳送Ack訊息。
4.完成事務。
協調者接收到所有參與者反饋的Ack訊息後,完成事務。
中斷事務
假如任何一個參與者向協調者反饋了No響應,或者在等待超時之後,協調者尚未接收到所有參與者的反饋響應,那麼就會中斷事務。
1.傳送回滾請求。
協調者向所有參與者節點發出Rollback請求。
2.事務回滾。
參與者接收到Rollback請求後,會利用氣在階段一中記錄的uno資訊來執行事務回滾操作,並在完成回滾之後釋放整個事務執行期間佔用的資源
3.反饋事務回滾結果。
參與者在完成事務回滾之後,向協調者傳送Ack訊息
4.中斷事務。
協調者收到所有參與者反饋的Ack訊息後,完成事務中斷
以上就是二階段提交過程中,前後兩個階段分別進行的處理邏輯。簡單講,二階段提交嘗試講一個事物的處理過程分為了投票和執行兩個階段,其核心是對每個事物都採取先嚐試後提交的方式,因此也可以將二階段提交看作是一個強一致性的演算法。”事物提交”和”事物中斷”兩種場景分別如圖所示:
2PC的優缺點
1、二階段提交協議的優點:
原理簡單、實現方便
2、二階段提交協議的缺點,重點講一下:
(1)同步阻塞
二階段提交協議存在的最明顯也是最大的一個問題就是同步阻塞,這會極大地限制分散式系統的效能。在二階段提交的執行過程中,所有參與該事物操作的邏輯都處於阻塞狀態,也就是說每個參與者在等待其他參與者響應的過程中,將無法進行其他任何操作
(2)單點問題
從上面的講解以及上圖中可以看出,協調者的角色在整個二階段提交協議中起到了非常重要的作用。一旦協調者出現問題,那麼整個二階段提交流程將無法運轉,更為嚴重的是,如果協調者是在階段二中出現問題的話,那麼其他參與者將一直處於鎖定事物資源的狀態中,而無法繼續完成事物操作
(3)資料不一致
在二階段提交協議的階段二,即執行事務提交的時候,當協調者向所有的參與者傳送Commit請求之後,發生了區域性網路異常或者是協調者在尚未傳送完Commit請求之前自身發生了崩潰,導致最終只有部分參與者收到了Commit請求。於是,這部分收到了Commit請求的參與者就會進行事務的提交,而其他沒有收到Commit請求的參與者則無法進行事物提交,於是整個分散式系統便出現了資料不一致的現象
(4)太過保守
如果在協調者指示參與者進行事務提交詢問的過程中,參與者出現故障而導致協調者始終無法獲取到所有參與者的響應的話,這時協調者只能依靠其自身的超時機制來判斷是否需要中斷事物,這樣的策略顯得比較保守。換句話說,二階段提交協議沒有設計較為完善的容錯機制,任意一個節點的失敗都會導致整個事物的失敗。
從PAXOS到ZOOKEEPER分散式一致性原理與實踐pdf下載:
http://download.csdn.net/detail/xunzaosiyecao/9867618
作者:jiankunking 出處:http://blog.csdn.net/jiankunking
相關文章
- 從PAXOS到ZOOKEEPER分散式一致性原理與實踐--Paxos演算法分散式演算法
- 從PAXOS到ZOOKEEPER分散式一致性原理與實踐--3PC(Three-Phase Commit)分散式MIT
- Redis、Zookeeper實現分散式鎖——原理與實踐Redis分散式
- 分散式一致性原理與實踐(一)分散式
- 使用GO實現Paxos分散式一致性協議Go分散式協議
- Paxos——分散式一致性演算法分散式演算法
- paxos分散式一致性演算法分散式演算法
- 分散式一致性演算法Paxos分散式演算法
- 分散式鎖實現原理與最佳實踐分散式
- 分散式一致性演算法-paxos詳解與分析分散式演算法
- zookeeper 分散式鎖的原理及實現分散式
- 讀《深入分散式快取 - 從原理到實踐》分散式快取
- 搞懂分散式技術2:分散式一致性協議與Paxos,Raft演算法分散式協議Raft演算法
- Zookeeper與paxos演算法演算法
- 分散式理論(五) - 一致性演算法Paxos分散式演算法
- 不能理解 two-phase commit!MIT
- 分散式一致性協議之2PC和3PC分散式協議
- memcached分散式原理與實現分散式
- 關於分散式鎖原理的一些學習與思考-redis分散式鎖,zookeeper分散式鎖分散式Redis
- 【zookeeper】zookeeper分散式鎖分散式
- The Two-Phase Commit Mechanism (149)MIT
- 搞懂分散式技術9:Nginx負載均衡原理與實踐分散式Nginx負載
- 分散式一致性協議Raft原理與例項分散式協議Raft
- 分散式-zookeeper分散式
- 分散式鎖之Zookeeper實現分散式
- 分散式鎖實現(二):Zookeeper分散式
- ZooKeeper分散式鎖的實現分散式
- 6 zookeeper實現分散式鎖分散式
- Zookeeper和Curator-Framework實踐之:分散式訊息佇列Framework分散式佇列
- 分散式資料庫事務故障恢復的原理與實踐分散式資料庫
- Redis從入門到高可用,分散式實踐(1)- 基礎介紹Redis分散式
- 從分散式一致性談到CAP理論、BASE理論分散式
- paxos-分散式系統資料一致性演算法學習分散式演算法
- R2M分散式鎖原理及實踐分散式
- 分散式協議與演算法-Paxos演算法分散式協議演算法
- zookeeper分散式鎖分散式
- 4.5 zookeeper分散式分散式
- ZooKeeper 分散式鎖分散式