之前看了林奇的mysql 45講，裡面提到了二階段提交，看的一頭霧水，後來又再別的地方看到了解釋，這裡做下記錄，方便理解。
1.字面意思，說白了就是提交分兩階段，準備階段和真實提交階段
由於乙個事件或者說事務，需要多方聯動配合，即保持(資料，業務，狀態)一致性，個人理解應該就是cap中的a吧，
可能進行到其中某個環節，由於網路，服務不穩定啊(cap中的p體現?)，等等原因，導致後續環節沒有執行，而前面的環節已經執行了，前面的環節並不知道後續環節執行失敗，會預設和自己一樣成功，從而修改當前環境的狀態，資料等，就會出現資料的不一致。
簡單來說，分布式系統，會出現資料不一致的問題。這是原因。
哪麼為了解決這個問題，就得知道後續環節是不是成功了，如果沒成功，大家都要按照每成功了，不能我成功了，你沒成功，大概就是事務的一致性體現吧。
所以，需要知道到你這環你能不能執行，這個事情，理論上我認為可以由上游操作，得到反饋，但是可能是為了抽離，專門會有乙個協作者的角色，來進行判斷和指揮（服務只負責提供功能，流程控制由協作者指導）。
所以，協作者需要判斷各服務是否可用，各服務是否能執行成功，這就是下面說的第一階段。
2.準備階段
協作者作為組織者，需要判斷各個參與者是否可用，參與者需反饋給協作者，協作者進行確認即可進行第二階段。
這裡的意思看起來有點無用，直接讓各參與者直接按照環節進行就可以，何必浪費這一步。
看了下mysql講義中，這一步貌似是進行了 undo資訊和redo資訊寫入日誌，即流程記錄。記錄當前事務發生到了哪個階段，
如果到時候，後續哪個環節炸了，可以按照記錄，將參與者都回滾到最初的狀態，說白了，個人理解：準備階段就是乙個判斷and記錄功能。
如果參與者無法提供功能，則直接提示全部失敗
參考:
Lucene二階段提交
indexwirter繼承了twophasecommit介面，實現三個方法 preparecommit，commit與rollback 二階段提交只是一種選擇,在通常情況下,只需要定時呼叫commit 方法做hardcommit即可.如果有分布式需求做版本控制等,可能會需要二階段提交 lucene自...
二階段提交協議，三階段提交協議
其實三者都是為了解決分布式一致性問題而存在的協議和演算法。首先先來了解幾個概念。協調者 coordinator 在分布式系統中，當事務操作需要跨越多個分布式節點的時候，為了保持分布式處理的acid特性，需要引入它來統一排程所有節點的執行邏輯。參與者 participant 協調者排程的這些節點就是參...
分布式事務 二階段提交與三階段提交
一 二階段提交演算法描述 在分布式系統中，事務往往包含有多個參與者的活動，單個參與者上的活動是能夠保證原子性的，而多個參與者之間原子性的保證則需要通過兩階段提交來實現，兩階段提交是分布式事務實現的關鍵。很明顯，兩階段提交保證了分布式事務的原子性，這些子事務要麼都做，要麼都不做。而資料庫的一致性是由資...