背景介紹
最近大家都相比遇到了就業瓶頸了，很多公司要不就是不招人了，要不就是把門檻擡的很高，是以針對于一些分布式角度而言的技術知識點，更是必備條件以及重中之重了。那麼今天筆者就針對于分布式協定以及一些算法原理進行詳細的分析和原理介紹。
分布式體系
分布式體系管理的主要内容是面對于分布式節點進行執行事務的操作流程。
整個分布式體系主要包含了幾個要素：
- 分布式節點
- 本地操作
- 分布式組合操作
如何可以将分布式節點的每個本地操作達成整齊劃一，并且實作統一化的資料狀态管理，這将是分布式協定 的重點管理目标和方向。
執行失敗狀态将會不一緻
但是如果一旦出現了其中某一個節點的本地執行出現錯誤，如下圖所示。
就會出現很嚴重的問題，導緻分布式節點的執行不完整，最終造成了資料狀态不一緻的問題。
分布式協定（2PC+3PC）
每一個分布式節點明确的知道自己執行的事務結果是成功還是失敗，但無法知道其他節點的執行結果， 是以為了保持事務的ACI特性， 需要引入一個“協調者”(Coordinator)來排程所有的分布式節點稱為“參與者”(Participant) 。基于這種思想衍生出了二階送出與三階送出兩種協定。
二階送出（Two-Phase Commit，2PC）
概念介紹
使基于分布式架構下的所有節點在進行事務處理過程中保持原子性與一緻性而設計的一種算法。
執行流程
- 階段一：送出事務請求
- 階段二：執行事務送出
階段一：送出事務請求
- 事務詢問：協調者向所有的參與者發送事務内容，詢問是否可以執行事務送出操作，并開始等待各個參與者響應。
- 執行事務：各參與者節點執行事務操作， 并将undo與redo資訊寫入事務日志中。
- 各參與者向協調者回報事務詢問的響應如果參與者成功執行了事務， 就傳回YES，如果不成功，就傳回NO。
該階段相當于各個參與者對協調者發送的事務内容進行是否可以執行的投票。
階段二：執行事務送出
根據參與者的響應，正常情況下有兩種情況：
- 成功：YES
- 失敗：NO
執行事務送出（響應都為YES）
- 發送送出請求
- 事務送出，協調者向所有參與者節點發出Commit請求，參與者接收到Commit請求後，會正式執行事務送出操作，并在完成後釋放事務，執行期間占用的資源
- 回報事務送出結果，參與者完成事務送出以後，向協調者發送Ack消息
- 完成事務，收到所有參與者節點的Ack消息後，完成事務
中斷事務（響應有NO，或有逾時）
- 發送復原請求，協調者向所有參與者節點發出Rollback請求
- 事務復原，參與者接收到Rollback請求後，會根據undo資訊執行執行事務復原操作，并在完成後釋放事務執行期間占用的資源。
- 回報事務復原結果，參與者完成事務復原以後，向協調者發送Ack消息。
- 中斷事務，收到所有參與者節點的Ack消息後，完成事務中斷
優點
- 原理簡單
- 實作友善
缺點
同步阻塞（性能較差）
在二段送出過程中，所有參與該事務操作的邏輯都處于阻塞狀态，也就是各個參與者在等待其他參與者響應的過程中都無法執行其他操作。
單點問題（容易造成崩潰）
協調者的角色在整個二段送出協定中起到了非常重要的作用，如果協調者出現問題，參與者将鎖定事務資源無法繼續完成事務操作。
資料不一緻（在二階段的問題）
在階段二過程中， 有可能因為網絡等原因出現隻有部分參與者收到了Commit請求。而出現各個節點資料不一緻的問題。
從太過保守
沒有容錯機制，任何一個節點的失敗都會導緻整個事務的中斷。
三階送出（Three-Phase Commit，3PC）
概述
2PC的改進版本，将2PC二階段送出的過程一分為二， 形成了Can Commit， Pre Commit， Do Commit三個階段組成的事務協定。
Can Commit階段
1. 事務詢問
事務協調者向所有的分布式節點發送一個包含事務内容的can Commit請求， 詢問是否可以執行事務送出操作，并開始等待各個參與者響應。
2.各參與者向協調者回報事務詢問的響應
如果參與者認為可以順利執行事務， 就回報YES， 并進入預備狀态， 否則回報NO
該階段相當于各個參與者對協調者發送的事務内容進行是否可以執行的投票
Pre Commit階段
根據參與者的響應，正常情況下有兩種情況：
1. 執行事務送出（響應都為YES）
- 發送預送出請求，協調者向所有參與者節點發出pre Commit請求， 并進入prepared階段
- 預事務送出，參與者接收到Pre Commit請求後， 會執行事務， 并将undo與redo資訊寫入事務日志中
- 回報事務送出結果，參與者完成事務送出以後， 向協調者發送Ack消息， 等待最終的指令：送出(Commit)或終止(abort)
2. 中斷事務（響應存在NO，或有逾時）
- 發送復原，請求協調者向所有參與者節點發出abort請求
- 中斷事務，收到所有參與者節點的Ack消息後， 或者等待協調者響應逾時， 都會中斷事務
Do Commit階段
根據參與者的響應，正常情況下有兩種情況：
執行送出（響應都為YES）
- 發送送出請求，協調者向所有參與者節點發出do Commit請求
- 事務送出，參與者接收到do Commit請求後， 會正式執行事務， 并在完成後釋放事務執行期間占用的資源
- 回報事務送出結果，參與者完成事務送出以後， 向協調者發送Ack消息
- 完成事務，收到所有參與者節點的Ack消息後， 完成事務
中斷事務（二階段送出後，參與者響應有NO， 或有逾時）
- 發送復原請求，協調者向所有參與者節點發出abort請求
- 事務復原，參與者接收到abort請求後， 會根據undo資訊執行事務復原操作， 并在完成後釋放事務執行期間占用的資源
- 回報事務復原結果，參與者完成事務復原以後， 向協調者發送Ack消息
- 中斷事務，收到所有參與者節點的Ack消息後， 或者等待協調者響應逾時， 都會中斷事務
優點
降低了二階段送出的阻塞範圍。
缺點
- 參與者收到pre Commit消息後， 一旦無法與協調者通信， 将在逾時後送出事務， 在這種情況下，可能會出現資料的不一緻性
- 協調者出現故障，協調者與參與者之間的網絡出現故障（旦參與者接收不到協調者的請求逾時以後，都會進行事務送出）