一：分布式一致性協議
--->對於一個分布式系統進行架構設計的過程中，往往會在系統的可用性和數據一致性之間進行反復的權衡，於是就產生了一系列的一致性協議。
--->長期探索涌現出一大批經典的一致性協議和算法。其中最著名的就是二階段提交協議，三階段提交協議和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消息后，如果網絡出現分區，此時協調者所在的節點和參與者無法進行正常網絡通信，在這種情況下，該參與者依然會進行事務提交，這必然出現數據不一致性。