分布式基礎(chǔ)知識
分布式的特點(diǎn)：分布性、對等性、并發(fā)性躏升、缺乏全局時(shí)鐘骄蝇、故障總會發(fā)生
分布式環(huán)境下的各種問題：通訊異常、網(wǎng)絡(luò)分區(qū)谷醉、成功失敗超時(shí)三態(tài)致稀、節(jié)點(diǎn)故障
事務(wù)一致性
數(shù)據(jù)庫事務(wù)包含：原子性（Atomicity）、一致性（Consistency）俱尼、隔離性（Isolation）抖单、持久性（Durability）
分布式事務(wù):
事務(wù)的參與者、支持事務(wù)的服務(wù)器遇八、資源服務(wù)器以及事務(wù)管理器位于分布式系統(tǒng)的不同節(jié)點(diǎn)上矛绘。
CAP定理：
一個(gè)分布式系統(tǒng)不可能同時(shí)滿足一致性（C:Consistency）、可用性（A:Availability）和分區(qū)容錯(cuò)性（P:Partition tolerance）這三個(gè)基本要求刃永，最多只能滿足其中的兩項(xiàng)蔑歌。
BASE理論：
Basically Available(基本可用）、Soft state(軟狀態(tài)）和Eventually consistent(最終一致性）三個(gè)短語的簡寫揽碘。BASE是對CAP中一致性和可用性權(quán)衡的結(jié)果次屠，其來源于對大規(guī)模互聯(lián)網(wǎng)系統(tǒng)分布式實(shí)踐的總結(jié)雳刺，是基于CAP定理逐步演化而來的劫灶，其核心思想是即使無法做到強(qiáng)一致性，但每個(gè)應(yīng)用都可以根據(jù)自身的業(yè)務(wù)特點(diǎn)掖桦，采用適當(dāng)?shù)姆椒▉硎瓜到y(tǒng)達(dá)到最終一致性本昏。
一致性協(xié)議：
2pc（請求處理-->提交確認(rèn)）與3pc（事務(wù)處理能力詢問-->處理后待提交-->提交確認(rèn)）
兩階段提交(2pc)
兩個(gè)階段是指：第一階段：準(zhǔn)備階段(投票階段)和第二階段：提交階段（執(zhí)行階段）。
準(zhǔn)備階段分為以下三個(gè)步驟：
1）協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)詢問是否可以執(zhí)行提交操作(vote)枪汪，并開始等待各參與者節(jié)點(diǎn)的響應(yīng)涌穆。
2）參與者節(jié)點(diǎn)執(zhí)行詢問發(fā)起為止的所有事務(wù)操作，并將Undo信息和Redo信息寫入日志雀久。（注意：若成功這里其實(shí)每個(gè)參與者已經(jīng)執(zhí)行了事務(wù)操作）
3）各參與者節(jié)點(diǎn)響應(yīng)協(xié)調(diào)者節(jié)點(diǎn)發(fā)起的詢問宿稀。如果參與者節(jié)點(diǎn)的事務(wù)操作實(shí)際執(zhí)行成功，則它返回一個(gè)”同意”消息赖捌；如果參與者節(jié)點(diǎn)的事務(wù)操作實(shí)際執(zhí)行失敗祝沸，則它返回一個(gè)”中止”消息。
提交階段
如果協(xié)調(diào)者收到了參與者的失敗消息或者超時(shí)，直接給每個(gè)參與者發(fā)送回滾(Rollback)消息罩锐；否則奉狈，發(fā)送提交(Commit)消息；參與者根據(jù)協(xié)調(diào)者的指令執(zhí)行提交或者回滾操作涩惑，釋放所有事務(wù)處理過程中使用的鎖資源仁期。(注意:必須在最后階段釋放鎖資源)
當(dāng)協(xié)調(diào)者節(jié)點(diǎn)從所有參與者節(jié)點(diǎn)獲得的相應(yīng)消息都為”同意”時(shí):
1）協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)發(fā)出”正式提交(commit)”的請求。
2）參與者節(jié)點(diǎn)正式完成操作竭恬，并釋放在整個(gè)事務(wù)期間內(nèi)占用的資源蟀拷。
3）參與者節(jié)點(diǎn)向協(xié)調(diào)者節(jié)點(diǎn)發(fā)送”完成”消息。
4）協(xié)調(diào)者節(jié)點(diǎn)受到所有參與者節(jié)點(diǎn)反饋的”完成”消息后萍聊，完成事務(wù)问芬。
當(dāng)任一參與者節(jié)點(diǎn)在第一階段返回的響應(yīng)消息為”中止”或協(xié)調(diào)者節(jié)點(diǎn)在第一階段的詢問超時(shí)之前無法獲取所有參與者節(jié)點(diǎn)的響應(yīng)消息時(shí):
1）協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)發(fā)出”回滾操作(rollback)”的請求。
2）參與者節(jié)點(diǎn)利用之前寫入的Undo信息執(zhí)行回滾寿桨，并釋放在整個(gè)事務(wù)期間內(nèi)占用的資源此衅。
3）參與者節(jié)點(diǎn)向協(xié)調(diào)者節(jié)點(diǎn)發(fā)送”回滾完成”消息。
4）協(xié)調(diào)者節(jié)點(diǎn)受到所有參與者節(jié)點(diǎn)反饋的”回滾完成”消息后亭螟，取消事務(wù)挡鞍。
二階段提交看起來確實(shí)能夠提供原子性的操作，但是不幸的事预烙，二階段提交還是有幾個(gè)缺點(diǎn)的：
1墨微、同步阻塞問題。執(zhí)行過程中扁掸，所有參與節(jié)點(diǎn)都是事務(wù)阻塞型的翘县。當(dāng)參與者占有公共資源時(shí)，其他第三方節(jié)點(diǎn)訪問公共資源不得不處于阻塞狀態(tài)谴分。
2锈麸、單點(diǎn)故障。由于協(xié)調(diào)者的重要性牺蹄，一旦協(xié)調(diào)者發(fā)生故障忘伞。參與者會一直阻塞下去。尤其在第二階段沙兰，協(xié)調(diào)者發(fā)生故障氓奈，那么所有的參與者還都處于鎖定事務(wù)資源的狀態(tài)中，而無法繼續(xù)完成事務(wù)操作鼎天。（如果是協(xié)調(diào)者掛掉舀奶，可以重新選舉一個(gè)協(xié)調(diào)者，但是無法解決因?yàn)閰f(xié)調(diào)者宕機(jī)導(dǎo)致的參與者處于阻塞狀態(tài)的問題）
3训措、數(shù)據(jù)不一致伪节。在二階段提交的階段二中，當(dāng)協(xié)調(diào)者向參與者發(fā)送commit請求之后绩鸣，發(fā)生了局部網(wǎng)絡(luò)異郴炒螅或者在發(fā)送commit請求過程中協(xié)調(diào)者發(fā)生了故障，這回導(dǎo)致只有一部分參與者接受到了commit請求呀闻。而在這部分參與者接到commit請求之后就會執(zhí)行commit操作化借。但是其他部分未接到commit請求的機(jī)器則無法執(zhí)行事務(wù)提交。于是整個(gè)分布式系統(tǒng)便出現(xiàn)了數(shù)據(jù)部一致性的現(xiàn)象捡多。
4蓖康、二階段無法解決的問題：協(xié)調(diào)者再發(fā)出commit消息之后宕機(jī)，而唯一接收到這條消息的參與者同時(shí)也宕機(jī)了垒手。那么即使協(xié)調(diào)者通過選舉協(xié)議產(chǎn)生了新的協(xié)調(diào)者蒜焊，這條事務(wù)的狀態(tài)也是不確定的，沒人知道事務(wù)是否被已經(jīng)提交科贬。
二階段提交存在著諸如同步阻塞泳梆、單點(diǎn)問題、腦裂等缺陷榜掌，所以优妙，研究者們在二階段提交的基礎(chǔ)上做了改進(jìn)，提出了三階段提交憎账。
三階段提交(3pc)
與兩階段提交不同的是套硼，三階段提交有兩個(gè)改動(dòng)點(diǎn)。
1胞皱、引入超時(shí)機(jī)制邪意。同時(shí)在協(xié)調(diào)者和參與者中都引入超時(shí)機(jī)制。
2反砌、在第一階段和第二階段中插入一個(gè)準(zhǔn)備階段抄罕。保證了在最后提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的。
也就是說于颖，除了引入超時(shí)機(jī)制之外呆贿，3PC把2PC的準(zhǔn)備階段再次一分為二，這樣三階段提交就有CanCommit森渐、PreCommit做入、DoCommit三個(gè)階段。
CanCommit階段
3PC的CanCommit階段其實(shí)和2PC的準(zhǔn)備階段很像同衣。協(xié)調(diào)者向參與者發(fā)送commit請求竟块，參與者如果可以提交就返回Yes響應(yīng)，否則返回No響應(yīng)耐齐。
1.事務(wù)詢問 協(xié)調(diào)者向參與者發(fā)送CanCommit請求浪秘。詢問是否可以執(zhí)行事務(wù)提交操作蒋情。然后開始等待參與者的響應(yīng)。
2.響應(yīng)反饋 參與者接到CanCommit請求之后耸携，正常情況下棵癣，如果其自身認(rèn)為可以順利執(zhí)行事務(wù)，則返回Yes響應(yīng)夺衍，并進(jìn)入預(yù)備狀態(tài)狈谊。否則反饋No
PreCommit階段
協(xié)調(diào)者根據(jù)參與者的反應(yīng)情況來決定是否可以記性事務(wù)的PreCommit操作。根據(jù)響應(yīng)情況沟沙，有以下兩種可能河劝。
假如協(xié)調(diào)者從所有的參與者獲得的反饋都是Yes響應(yīng)，那么就會執(zhí)行事務(wù)的預(yù)執(zhí)行矛紫。
1.發(fā)送預(yù)提交請求 協(xié)調(diào)者向參與者發(fā)送PreCommit請求赎瞎，并進(jìn)入Prepared階段。
2.事務(wù)預(yù)提交 參與者接收到PreCommit請求后颊咬，會執(zhí)行事務(wù)操作煎娇，并將undo和redo信息記錄到事務(wù)日志中。
3.響應(yīng)反饋 如果參與者成功的執(zhí)行了事務(wù)操作贪染，則返回ACK響應(yīng)缓呛，同時(shí)開始等待最終指令。
假如有任何一個(gè)參與者向協(xié)調(diào)者發(fā)送了No響應(yīng)杭隙，或者等待超時(shí)之后哟绊，協(xié)調(diào)者都沒有接到參與者的響應(yīng)，那么就執(zhí)行事務(wù)的中斷痰憎。
1.發(fā)送中斷請求 協(xié)調(diào)者向所有參與者發(fā)送abort請求票髓。
2.中斷事務(wù) 參與者收到來自協(xié)調(diào)者的abort請求之后（或超時(shí)之后，仍未收到協(xié)調(diào)者的請求）铣耘，執(zhí)行事務(wù)的中斷洽沟。
doCommit階段
該階段進(jìn)行真正的事務(wù)提交，也可以分為以下兩種情況蜗细。
執(zhí)行提交
1.發(fā)送提交請求 協(xié)調(diào)接收到參與者發(fā)送的ACK響應(yīng)裆操，那么他將從預(yù)提交狀態(tài)進(jìn)入到提交狀態(tài)。并向所有參與者發(fā)送doCommit請求炉媒。
2.事務(wù)提交 參與者接收到doCommit請求之后踪区，執(zhí)行正式的事務(wù)提交。并在完成事務(wù)提交之后釋放所有事務(wù)資源吊骤。
3.響應(yīng)反饋 事務(wù)提交完之后缎岗，向協(xié)調(diào)者發(fā)送Ack響應(yīng)。
4.完成事務(wù) 協(xié)調(diào)者接收到所有參與者的ack響應(yīng)之后白粉，完成事務(wù)传泊。
中斷事務(wù) 協(xié)調(diào)者沒有接收到參與者發(fā)送的ACK響應(yīng)（可能是接受者發(fā)送的不是ACK響應(yīng)鼠渺，也可能響應(yīng)超時(shí)），那么就會執(zhí)行中斷事務(wù)眷细。
1.發(fā)送中斷請求 協(xié)調(diào)者向所有參與者發(fā)送abort請求
2.事務(wù)回滾 參與者接收到abort請求之后拦盹，利用其在階段二記錄的undo信息來執(zhí)行事務(wù)的回滾操作，并在完成回滾之后釋放所有的事務(wù)資源薪鹦。
3.反饋結(jié)果 參與者完成事務(wù)回滾之后掌敬，向協(xié)調(diào)者發(fā)送ACK消息
4.中斷事務(wù) 協(xié)調(diào)者接收到參與者反饋的ACK消息之后惯豆，執(zhí)行事務(wù)的中斷池磁。
在doCommit階段，如果參與者無法及時(shí)接收到來自協(xié)調(diào)者的doCommit或者rebort請求時(shí)楷兽，會在等待超時(shí)之后地熄，會繼續(xù)進(jìn)行事務(wù)的提交。（其實(shí)這個(gè)應(yīng)該是基于概率來決定的芯杀，當(dāng)進(jìn)入第三階段時(shí)端考，說明參與者在第二階段已經(jīng)收到了PreCommit請求，那么協(xié)調(diào)者產(chǎn)生PreCommit請求的前提條件是他在第二階段開始之前揭厚，收到所有參與者的CanCommit響應(yīng)都是Yes却特。（一旦參與者收到了PreCommit，意味他知道大家其實(shí)都同意修改了）所以筛圆，一句話概括就是裂明，當(dāng)進(jìn)入第三階段時(shí)，由于網(wǎng)絡(luò)超時(shí)等原因太援，雖然參與者沒有收到commit或者abort響應(yīng)闽晦，但是他有理由相信：成功提交的幾率很大。 ）
2PC與3PC的區(qū)別
相對于2PC提岔，3PC主要解決的單點(diǎn)故障問題仙蛉，并減少阻塞，因?yàn)橐坏﹨⑴c者無法及時(shí)收到來自協(xié)調(diào)者的信息之后碱蒙，他會默認(rèn)執(zhí)行commit荠瘪。而不會一直持有事務(wù)資源并處于阻塞狀態(tài)。但是這種機(jī)制也會導(dǎo)致數(shù)據(jù)一致性問題赛惩，因?yàn)榍苫梗捎诰W(wǎng)絡(luò)原因，協(xié)調(diào)者發(fā)送的abort響應(yīng)沒有及時(shí)被參與者接收到坊秸，那么參與者在等待超時(shí)之后執(zhí)行了commit操作麸祷。這樣就和其他接到abort命令并執(zhí)行回滾的參與者之間存在數(shù)據(jù)不一致的情況。
無論是二階段提交還是三階段提交都無法徹底解決分布式的一致性問題褒搔。Google Chubby的作者M(jìn)ike Burrows說過阶牍， there is only one consensus protocol, and that’s Paxos” – all other approaches are just broken versions of Paxos. 意即世上只有一種一致性算法喷面，那就是Paxos算法。
