三：分佈式事務一致性協議2pc和3pc

一：分佈式一致性協議
--->對於一個分佈式系統進行架構設計的過程當中，每每會在系統的可用性和數據一致性之間進行反覆的權衡，因而就產生了一系列的一致性協議。
--->長期探索涌現出一大批經典的一致性協議和算法。其中最著名的就是二階段提交協議，三階段提交協議和paxos算法。


二：2PC與3PC
--->在分佈式系統中，每個機器節點雖然都可以明確知道本身在進行事務操做過程當中的結果是成功或失敗，但卻沒法直接獲取到其餘分佈式節點的操做結果。所以，當一個事務操做須要跨越多個分佈式節點的時候，爲了保持事務處理的ACID特性，就須要引入一個稱爲「協調者」的組件來統一調度全部分佈式節點的執行邏輯，這些被調度的分佈式節點則被稱爲「參與者」。
--->協調者負責調度參與者的行爲，並最終決定這些參與者是否要把事務真正進行提交。
--->基於這個思想，衍生出了二階段提交和三階段提交兩種協議。


三：2PC
【1】2pc概念
---->2PC，是Two-Phase Commit的所寫，即二階段提交，是計算機網絡尤爲是在數據庫領域內，爲了使基於分佈式系統架構下的全部節點在進行事務處理過程當中可以保持原子性和一致性而設計的一種算法。
---->一般，二階段提交協議也被認爲是一種一致性協議，用來保證分佈式系統數據一致性。
---->目前，絕大部分的關係型數據庫都是採用二階段提交協議來完成分佈式事務處理的。利用該協議可以很是方便地完成全部分佈式事務參與者的協調，統一決定事務的提交或回滾，從而可以有效地保證分佈式數據一致性，所以二階段提交協議被普遍地應用在許多分佈式系統中。


【2】2PC說明
--->顧名思義，二階段提交協議是將事務的提交過程分紅兩個階段進行處理，其執行流程以下。
●階段一：提交事務請求（投票階段）
        1,事務詢問：協調者向全部參與者發送事務內容，詢問是否能夠執行事務提交操做，並開始等待各參與者的響應。
        2,執行事務：各參與者節點執行事務操做，並將Undo和Redo信息計入事務日誌中。
        3,各參與者向協調者反饋事務詢問的響應。若是參與者成功執行了事務操做，那麼就反饋給協調者yes響應，表示事務能夠執行；若是參與者沒有成功執行事務操做，那麼就反饋給協調者No響應，表示事務不能夠執行。


●階段二：執行事務提交（根據投票結果肯定最終實施）
在階段二中，協調者會根據各參與者的反饋狀況來決定最終是否能夠進行事務提交操做，正常狀況下，包含如下兩種可能。
        《1》執行事務提交：假如協調者從全部的參與者得到的反饋是Yes響應，那麼會執行事物提交。
                ==>1發送提交請求：協調者向全部參與者節點發出Commit請求
                ==>2事務提交：參與者接受到Commit請求後，會正式執行事務提交操做，並在完成提交以後釋放整個事務執行期間佔用的事務資源。
                ==>3反饋事務提交結果：參與者在完成事務提交以後，向協調者發送Ack消息
                ==>4完成事務：協調者接收到全部參與者反饋的Ack消息後，完成事務。

        《2》中斷事務：假如任何一個參與者向協調者反饋了No響應，或者在等待超時以後，協調者尚沒法接受到全部參與者的反饋響應，那麼事務中斷。
                ==>1發送回滾請求：協調者向全部參與者節點發送Rollback請求
                ==>2事務回滾：參與者接收到Rollback請求後，會利用其在階段一中記錄的Undo信息來執行事務回滾操做，並在完成回滾以後釋放在整個事務執行期間佔用的資源。
                ==>3反饋事務回滾結果：參與者在完成事務回滾以後，向協調者發送Ack消息
                ==>4中斷事務：協調者接收到全部參與者反饋的Ack消息後，完成事務中斷。


【3】：2PC優勢和缺點
--->二階段提交協議的優勢：原理簡單，實現方便
--->二階段提交協議的缺點 ：同步阻塞，單點問題，腦裂，太過保守
   ●同步阻塞：
        ==>極大限制分佈式系統性能
        ==>各個參與者完成時間不一，必然存在某些參與者等待其餘未完成參與者完成事務操做。在等待過程當中沒法執行其餘任何操做。
  ●單點問題：
        ==>協調者佔據主導地位
        ==>一旦協調者出出現問題，那麼整個事務則沒法完成，尤爲是在階段二中出現問題，各個參與者所鎖定的資源將沒法釋放。致使其餘業務不能操做
   ●腦裂致使數據不一致：
        ==>若是分佈式節點出現網絡分區，某些參與者未收到commit提交命令。則出現部分參與者完成數據提交。未收到commit的命令的參與者則沒法進行事務提交。整個分佈式系統便出現了數據不一致性現象。
   ●太過保守：
        ==>協調者指示參與者進行事務提交詢問的過程當中，參與者出現故障致使協調者始終沒法獲取到全部參與者的相應信息的花，這時協調者只能靠自身的超時機制來判斷是否須要中斷事務，這樣的策略顯得保守。換句話說，二階段提交協議沒有設計較爲完善的容錯機制，任意一個節點故障會致使整個事務失敗。

 

 

 

四：3PC
【1】3pc概念
--->因爲2pc協議存在同步阻塞，協調者單點問題，腦裂（網絡分區）和太過保守的容錯機制等缺點。所以在二階段提交協議的基礎上進行改進，提出了三階段提交協議。
--->三階段提交協議，是2pc的改進版，其將二階段提交協議「提交事務請求」過程一分爲二，造成了由CanCommit,PreCommit和do Commit三個階段組成事務處理協議。
【2】3PC說明
●階段一：CanCommit(可否提交)
        1,事務詢問：協調者向全部的參與者發送一個包含事務內容的canCommit請求，詢問是否能夠執行事務提交操做，並開始等待各個參與者響應。
        2,各參與者向協調者反饋事務詢問的響應：參與者在接收到來自協調者的canCommit請求後，正常狀況下，若是其自身認爲能夠順利執行事務，那麼會反饋Yes響應，並進入預備狀態，不然反饋No


●階段二：PreCommit（預提交）
在階段二中，協調者會根據各個參與者的反饋狀況來決定是否能夠進行事務的PreCommit操做，正常狀況下，包含兩種可能。
《1》執行事務預提交
        假如協調者從全部的參與者得到的反饋都是Yes響應，那麼進入Prepared階段
        ==>1發送預提交請求：協調者向全部參與者節點發出preCommit的請求，並進入Prepared階段。
        ==>2事務預提交：參與者接收到preCommit請求後，會執行事務操做，並將Undo和Redo信息記錄到事務日誌中。
        ==>3各參與者向協調者反饋事務執行的響應：若是參與者成功執行了事務操做，那麼就會反饋給協調者Ack響應，同時等待最終的指令：提交（commit）或停止（abort）

《2》中斷事務
        假如任何一個參與者向協調者反饋了No響應，或者在等待超時以後，協調者尚沒法接收到全部參與者的反饋響應，那麼就會中斷事務。
        ==>1,發送中斷請求：協調者向全部參與者節點發出abort請求。
        ==>2,中斷事務：不管是收到來自協調者abort請求，或者是在等待協調者請求過程當中出現超時，參與者都會中斷事務。【參與者在預提交請求來臨階段，參與者收不到命令會中斷事務】


●階段三：doCommit（預提交）
        該階段將進行真正的事務提交，會存在如下兩種可能狀況
        《1》執行提交
                ==>1,發送提交請求：進入這一階段，假設協調者處於正常工做狀態，而且它接受到了來自參與者的Ack響應，那麼它將從「預提交」狀態轉換到「提交」狀態，並向全部的參與者發送doCommit請求。
                ==>2,事務提交：參與者接收到doCommit請求後，會正式執行事務提交操做，並在完成提交以後釋放在整個事務執行期間佔用的事務資源。
                ==>3,反饋事務提交結果：參與者在完成事務提交以後，向協調者發送Ack消息
                ==>4,完成事務：協調者接收到全部參與者反饋的Ack消息後，完成事務。

        《2》中斷事務
                進入這一階段，假設協調者處於正常工做狀態，而且有任意一個參與者向協調者反饋了No響應，或者在等待超時以後，協調者尚沒法接收到全部參與者反饋響應，那麼就會中斷事務。
                ==>1，發送中斷請求:協調者向全部的參與者節點發送abort請求
                ==>2,事務回滾：參與者接收到abort請求後，會利用其在階段二中記錄的Undo信息來執行事務回滾操做，並在完成回滾以後釋放在整個事務執行期間的資源。
                ==>3,反饋事務回滾結果：參與者在完成事務回滾以後，向協調者發送Ack消息。
                ==>4,中斷事務：協調者接收到全部參與者反饋的Ack消息後，中斷事務。


【3】3PC注意事項
        須要注意的是，一旦進入階段三，可能會存在如下兩種故障。
        ●協調者出現問題
        ●協調者和參與者之間的網絡出現故障
        不管出現哪一種狀況，最終都會致使參與者沒法及時接收到來自協調者的doCommit或是abort請求，針對這樣的異常狀況，參與者都會在等待超時以後，繼續進行事務提交。【參與者在等待協調者發送最終提交請求來臨階段，參與者超時未獲得協調者的真正提交請求，會自動提交事務】




【4】3PC優勢和缺點
         ●三階段提交協議的優勢：相較於二階段提交協議，三階段提交協議最大的優勢就是下降了參與者的阻塞範圍，而且可以在出現單點故障後繼續達成一致。
         ●三階段提交協議的缺點：三階段提交協議在去除阻塞的同時也引入了新問題，那就是在參與者接收到preCommit消息後，若是網絡出現分區，此時協調者所在的節點和參與者沒法進行正常網絡通訊，在這種狀況下，該參與者依然會進行事務提交，這必然出現數據不一致性。