從這週開始深入學習zookeeper，主要是看paxos到zookeeper分布式一致性理論與實踐以及zookeeper3.5的原始碼，在整個學習過程中會整理一些學習筆記。
1.分布式基本概念
2.一致性協議
2pc即兩階段提交，是計算機網路尤其是在資料庫領域內，為了使基於分布式系統架構下的所有節點在進行事務處理過程中能夠保持原子性和一致性而設計的一種演算法。兩階段提交將事務處理過程分為投票階段和執行階段兩個步驟，其核心是採用先嘗試後提交的處理方式。兩階段提交協議將事務的提交過程分成兩個階段來進行處理，其執行流程如下：
階段一：提交事務請求
事務詢問。協調者向所有的事務參與者傳送事務內容，詢問是否可以執行事務的提交操作，並等待個參與者的響應。
執行事務。各參與者執行事務操作，並將undo和redo資訊記入事務日誌。
各參與者向協調者反饋事務響應。如果參與者成功執行了事務操作，反饋yes，表示事務可以執行；如果參與者沒有成功執行事務，反饋no，表示事務不可以執行。
階段二：執行事務提交
傳送提交請求：協調者向所有參與節點發出commit請求
事務提交參與者收到commit請求後，執行事務提交操作，並在完成後釋放占用的資源；
反饋提交結果：參與者在完成事務提交之後，向協調者傳送ack訊息。
完成事務：協調者收到所有ack後，完成事務。
傳送回滾請求。協調者向參與者傳送rollback請求
事務回滾。參與者接收到rollback請求後，會利用undo資訊執行回滾操作，並釋放占用的資源。
反饋事務回滾結果
中斷事務。協調者接收到所有參與者的ack訊息後，完成事務中斷。
優點：原理簡單，實現方便。
缺點：
同步阻塞。在兩階段提交過程中，所有參與者事務操作都處於阻塞狀態，各個參與者在等待其他參與者響應。
單點問題。
資料不一致。
3pc即三階段提交，其將二階段提交協議的「提交事務請求」的過程一分為二，形成了cancommit、precommit和docommit三個階段。
階段一：cancommit
事務詢問。協調者向所有參與者傳送包含事務內容的cancommit請求，詢問是否可以執行事務提交操作。
參與者向協調者反饋事務詢問的響應。如果可以順利執行反饋yes，否則反饋no響應。
階段二：precommit
該階段協調者根據參與者的反饋決定是否可以順利進行事務的precommit操作。
傳送預提交請求。協調者向所有參與者發出precommit請求，並進入prepared階段。
事務預提交。參與者接收到precommit請求後執行事務操作，並將undo和redo資訊記錄到事務日誌中
各參與者向協調者反饋事務執行的響應。如果參與者成功提交了事務操作，返回ack，同時等待最終指令：提交（commit）或中止（abort）。
協調者傳送中斷（abort）請求
參與者中斷事務。（協調者傳送abort或者參與者等待超時）
階段三：docommit
協調者從precommit狀態轉換到「提交」狀態，並向所有的參與者傳送docommit請求。
參與者接收到docommit請求後，執行事務提交
參與者向協調者傳送ack訊息。
協調者接收到所有參與者的反饋ack訊息後，完成事務。
協調者傳送中斷請求
事務回滾。
反饋事務回滾結果。
中斷事務。
需要注意的是，一旦進入階段三不論協調者出現問題還是協調者與參與者網路之間的故障，最終都會導致參與者無法及時收到來自協調者大額docommit或者abort請求，針對這種異常情況，參與者在等待超時後，繼續進行事務的提交。
和二階段提交協議相比，三階段提交協議最大的優點就是降低了參與者的阻塞返回，並且能夠在出現單點故障後繼續達成一致。
一致性協議
節點在進行事務處理過程中保持原子性和一致性而設計的一種演算法。1.事務詢問。2.執行事務。3.各參與者向協調者反饋事務詢問的響應。理解 類似協調者組織各參與者對一次事務操作進行投票表態的過程。假如參與者全部反饋yes 1.傳送提交請求 2.事務提交 3.反饋事務提交結果 4.完成事務。假如任何乙個參...
一致性協議
在分布式系統中，每乙個機器節點雖然都能夠明確地知道自己在進行事務操作過程中的結果是成功或失敗，但卻無也直接獲取到其他分布式節點的操作結果。因此，當乙個事務操作需要跨越多個分布式節點的時候，為了保持事務處理的acid特性，就需要引人乙個稱為 協調者 的元件來統一排程所有分布式節點的執行邏輯，這些被排程...
一致性協議
在分布式系統中，當乙個事務操作需要跨越多個分布式節點的時候，為了保持事務acid的特徵，就需要引入乙個稱為 協調者 coordinator 的元件來統一排程所有分布式節點的執行邏輯，這些被排程的節點則稱為 參與者 participant 協調者負責參與者的行為，並最終決定這些參與者是否要把事務真正提...