在聊分布式一緻性問題前，我們先來談談什麼是CAP理論。
在分布式系統環境下，由于存在硬體、網絡的隔離，對于一些事務操作不像單機環境下那樣簡單，于是出現了CAP理論。它的定義如下：
- Consistency（一緻性）
由于分布式環境存在多個節點，這些節點上的資料在同一時間所存儲的資料必須是一緻的，這就是一緻性協定。在并發環境下一個用戶端從任何一個節點擷取的資料如何保證是最新的。對于服務端來說，需要保證在整個分布式環境下的資料複制問題。
- Availability（可用性）
可用性很好了解，任何時刻需要保證服務的可用和穩定。
- Partition Tolerance（分區容錯）
所謂分區容錯是指某個時刻出現網絡或者硬體不可用，甚至當機，其它的機器還能保證正常可用。
大部分情況下我們能夠很好的保證可用性和分區容錯，但是對于一緻性問題一直很難保證。業界對于解決一緻性問題常用的法則有三種：
二階段送出（2PC）
1、送出階段
協調者向參與者發起事務指令，參與者接收到事務指令進行本地事務的undo或redo操作，但不進行事務送出，将執行結果回報給協調者，大緻流程如下：
2、執行階段
通過在送出階段接收到參與者的回報，做出相應的動作。如果全部是成功，則向參與者發送指令進行事務的送出，否則隻要有一個失敗，則進行事務的復原。
二階段送出帶來的問題：
- 參與者與協調者的互動流程為阻塞性，意味着這期間其它的一些請求處理被阻塞了
- 協調者出現故障時，所有事務都處于待送出狀态，無法恢複
- 無法解決資料不一緻問題，當第二階段進行事務的送出過程中，如果任何一個節點出現不可用，協調者無法感覺到
通過以上三種缺點帶來了另外一種解決方案：三階段送出(3PC)
三階段送出（3PC）
三階段送出相比于兩階段送出優化了第一部分，加入了請求詢問及執行響應結果的ack。
1、canCommit
協調者首先詢問參與者是否可以進行事務指令，參與者應答協調者yes或no
2、preCommit
這時候有兩種情況：
- 當所有參與者傳回yes應答，則發送preCommit指令進行事務的本地預送出，當每個參與者事務進行完畢，給協調者進行回報ack。
- 隻要任何一個參與者在第一個确認簡單傳回了no，本次事務中斷，或者任何事務預送出送出階段逾時或無回報，本次事務中斷。
3、doCommit
目前面兩個階段執行完畢，協調者收到了每一個參與者應答ack，則進行doCommit指令，真正的事務送出，當所有的事務都已送出則傳回haveCommitAck，以便協調者知道事務是否真正送出，下面梳理了整個流程筆記：
3PC相比于2PC，解決了逾時及每個階段節點的狀态回報，但是也無法解決另外一個問題，當在預送出階段，進行事務回撤處理時，某個節點由于網絡原因未收到請求，則帶了資料的不一緻性，是以針對這個問題，有一種算法(Paxos)解決了此問題，例如zookeeper就是采用這種算法，至于zookeeper的一些實作細節，我們找時間在進行分享。
敬請持續關注“聊點源碼”微信公衆賬号！
【長按下方微信，擷取更多資訊】
你還在等什麼？