1. CAP定理
CAP定理是2000年，由 Eric Brewer 提出來的。Brewer認為在分布式的環(huán)境下設(shè)計和部署系統(tǒng)時，有3個核心的需求，以一種特殊的關(guān)系存在。這里的分布式系統(tǒng)說的是在物理上分布的系統(tǒng)，比如我們常見的web系統(tǒng)。
Consistency: 一致性，在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時刻是否同樣的值。(所有的節(jié)點上的數(shù)據(jù)時刻保持同步)
Availability: 可用性，在集群一部分節(jié)點出現(xiàn)故障知乎，集群整體是否還能響應客戶端的讀寫請求。(每個請求都能接受到一個響應，無論響應成功或失敗)
Partition Tolerance: if the network stops delivering messages between two sets of servers, will the system continue to work correctly(系統(tǒng)應該能持續(xù)提供服務(wù)，即使系統(tǒng)內(nèi)部有消息丟失（分區(qū)）)。
高可用、數(shù)據(jù)一致是很多系統(tǒng)設(shè)計的目標，但是分區(qū)又是不可避免的事情：
CA without P：如果不要求P（不允許分區(qū)），則C（強一致性）和A（可用性）是可以保證的。但其實分區(qū)不是你想不想的問題，而是始終會存在，因此CA的系統(tǒng)更多的是允許分區(qū)后各子系統(tǒng)依然保持CA。
CP without A：如果不要求A（可用），相當于每個請求都需要在Server之間強一致，而P（分區(qū)）會導致同步時間無限延長，如此CP也是可以保證的。很多傳統(tǒng)的數(shù)據(jù)庫分布式事務(wù)都屬于這種模式。
AP wihtout C：要高可用并允許分區(qū)，則需放棄一致性。一旦分區(qū)發(fā)生，節(jié)點之間可能會失去聯(lián)系，為了高可用，每個節(jié)點只能用本地數(shù)據(jù)提供服務(wù)，而這樣會導致全局數(shù)據(jù)的不一致性。現(xiàn)在眾多的NoSQL都屬于此類。
CAP原理的關(guān)系與相關(guān)的產(chǎn)品如下圖所示
下面是對于P的一點討論，在Seth Gilbert and Professor Nancy Lynch 論文中，Partition Tolerance的定義如下所示
"The network will be allowed to lose arbitrarily many messages sent from one node to anothe"
由此可見，分區(qū)容忍性并不是分布式應用的屬性，而是承載分布式應用的網(wǎng)絡(luò)的屬性，這是比較容易讓人誤解的情況。分區(qū)容忍不是我們設(shè)計分布式系統(tǒng)的一個選擇，筆者理解是設(shè)計分布式系統(tǒng)必須考慮分區(qū)的問題。在一個網(wǎng)絡(luò)中如果有分區(qū)（網(wǎng)絡(luò)故障或機器軟硬件故障），則會失去一致性C（因為允許更新分區(qū)的兩側(cè)）或者可用性A （因為您檢測到錯誤并關(guān)閉系統(tǒng)，直到錯誤條件解決）。分區(qū)容忍意味著通過選擇其他系統(tǒng)屬性中的哪一個來簡單地開發(fā)應對策略。
如果一個網(wǎng)絡(luò)存在信息丟失，那么在此網(wǎng)絡(luò)上構(gòu)建的分布式系統(tǒng)的可用性和一致性只能滿足一個。
2. 數(shù)據(jù)一致性模型
強一致性： 要求無論更新操作實在哪一個副本執(zhí)行，之后所有的讀操作都要能獲得最新的數(shù)據(jù)。
弱一致性：用戶讀到某一操作對系統(tǒng)特定數(shù)據(jù)的更新需要一段時間，我們稱這段時間為“不一致性窗口”。
最終一致性：是弱一致性的一種特例，保證用戶最終能夠讀取到某操作對系統(tǒng)特定數(shù)據(jù)的更新。
3. 數(shù)據(jù)一致性實現(xiàn)
1. Quorum系統(tǒng)NRW策略
這個協(xié)議有三個關(guān)鍵字N、R、W。
- N代表數(shù)據(jù)所具有的副本數(shù)。
- R表示完成讀操作所需要讀取的最小副本數(shù)，即一次讀操作所需要參與的最小節(jié)點數(shù)目。
- W表示完成寫操作所需要寫入的最小副本數(shù)，即一次寫操作所需要參與的最小節(jié)點數(shù)目。
則 N 和 R+N的關(guān)系有三種情況
N < R+W ,保證強一致性
N=3，W=2，R=2，那么表示系統(tǒng)中數(shù)據(jù)有3個不同的副本，當進行寫操作時，需要等待至少有2個副本完成
了該寫操作系統(tǒng)才會返回執(zhí)行成功的狀態(tài)，對于讀操作，系統(tǒng)有同樣的特性。由于R + W > N，因此該系統(tǒng)
是可以保證強一致性的。因為讀取數(shù)據(jù)的節(jié)點和被同步寫入的節(jié)點是有重疊的。
N >= R+W , 只能保證最終一致性
這時讀取和寫入操作是不重疊的，系統(tǒng)只能保證最終一致性，而副本達到一致的時間則依賴于系統(tǒng)異步更新
的實現(xiàn)方式，不一致性的時間段也就等于從更新開始到所有的節(jié)點都異步完成更新之間的時間。
R 和 W 比例關(guān)系
1. 當W=1,R=N時，系統(tǒng)對寫操作有較高的要求，但讀操作會比較慢，若N個節(jié)點中有節(jié)點發(fā)生故障，那么讀
操作將不能完成。
2. 當R=1,W=N時，系統(tǒng)對讀操作有較高性能、高可用，但寫操作性能較低，用于需要大量讀操作的系統(tǒng)，
若N個節(jié)點中有節(jié)點發(fā)生故障，那么些操作將不能完成。
3. 當R=Q,W=Q(Q=N/2+1)時，系統(tǒng)在讀寫性能之間取得平衡，兼顧了性能和可用性。
2. 兩階提交算法
在兩階段提交協(xié)議中，系統(tǒng)一般包含兩類機器（或節(jié)點）：一類為協(xié)調(diào)者（coordinator），通常一個系統(tǒng)中
只有一個；另一類為事務(wù)參與者（participants，cohorts或workers），一般包含多個，在數(shù)據(jù)存儲系統(tǒng)中可
以理解為數(shù)據(jù)副本的個數(shù)。兩階段提交協(xié)議由兩個階段組成，在正常的執(zhí)行下，這兩個階段的執(zhí)行過程如下
所述：
階段1：請求階段（commit-request phase，或稱表決階段，voting phase）。
在請求階段，協(xié)調(diào)者將通知事務(wù)參與者準備提交或取消事務(wù)，然后進入表決過程。在表決過程中，參與者將
告知協(xié)調(diào)者自己的決策：同意（事務(wù)參與者本地作業(yè)執(zhí)行成功）或取消（本地作業(yè)執(zhí)行故障）。
階段2：提交階段（commit phase）。
在該階段，協(xié)調(diào)者將基于第一個階段的投票結(jié)果進行決策：提交或取消。當且僅當所有的參與者同意提交事
務(wù)協(xié)調(diào)者才通知所有的參與者提交事務(wù)，否則協(xié)調(diào)者將通知所有的參與者取消事務(wù)。參與者在接收到協(xié)調(diào)者
發(fā)來的消息后將執(zhí)行響應的操作。
舉個例子：A組織B、C和D三個人去爬長城：如果所有人都同意去爬長城，那么活動將舉行；如果有一人不
同意去爬長城，那么活動將取消。用2PC算法解決該問題的過程如下：
首先A將成為該活動的協(xié)調(diào)者，B、C和D將成為該活動的參與者。
階段1：A發(fā)郵件給B、C和D，提出下周三去爬山，問是否同意。那么此時A需要等待B、C和D的郵件。B、
C和D分別查看自己的日程安排表。B、C發(fā)現(xiàn)自己在當日沒有活動安排，則發(fā)郵件告訴A它們同意下周三去
爬長城。由于某種原因，D白天沒有查看郵件。那么此時A、B和C均需要等待。到晚上的時候，D發(fā)現(xiàn)了A的
郵件，然后查看日程安排，發(fā)現(xiàn)周三當天已經(jīng)有別的安排，那么D回復A說活動取消吧。
階段2：此時A收到了所有活動參與者的郵件，并且A發(fā)現(xiàn)D下周三不能去爬山。那么A將發(fā)郵件通知B、C和
D，下周三爬長城活動取消。此時B、C回復A“太可惜了”，D回復A“不好意思”。至此該事務(wù)終止。
兩階段提交算法在分布式系統(tǒng)結(jié)合，可實現(xiàn)單用戶對文件（對象）多個副本的修改，多副本數(shù)據(jù)的同步。其
結(jié)合的原理如下：
客戶端（協(xié)調(diào)者）向所有的數(shù)據(jù)副本的存儲主機（參與者）發(fā)送：修改具體的文件名、偏移量、數(shù)據(jù)和長度
信息，請求修改數(shù)據(jù)，該消息是1階段的請求消息。
存儲主機接收到請求后，備份修改前的數(shù)據(jù)以備回滾，修改文件數(shù)據(jù)后，向客戶端回應修改成功的消息。如
果存儲主機由于某些原因（磁盤損壞、空間不足等）不能修改數(shù)據(jù)，回應修改失敗的消息。
客戶端接收發(fā)送出去的每一個消息回應，如果存儲主機全部回應都修改成功，向每存儲主機發(fā)送確認修改的
提交消息；如果存在存儲主機回應修改失敗，或者超時未回應，客戶端向所有存儲主機發(fā)送取消修改的提交
消息。該消息是2階段的提交消息。
存儲主機接收到客戶端的提交消息，如果是確認修改，則直接回應該提交OK消息；如果是取消修改，則將修
改數(shù)據(jù)還原為修改前，然后回應取消修改OK的消息。
客戶端接收全部存儲主機的回應，整個操作成功。
在該過程中可能存在通信失敗，例如網(wǎng)絡(luò)中斷、主機宕機等諸多的原因，對于未在算法中定義的其它異常，
都認為是提交失敗，都需要回滾，這是該算法基于確定的通信回復實現(xiàn)的，在參與者的確定回復（無論是回
復失敗還是回復成功）之上執(zhí)行邏輯處理，符合確定性的條件當然能夠獲得確定性的結(jié)果哲學原理。
缺點：單個A是個嚴重問題：沒有熱備機制，A節(jié)點宕機了或者鏈接它的網(wǎng)絡(luò)壞了會阻塞該事務(wù)；吞吐量不
行，沒有充分發(fā)動更多A的力量，一旦某個A第一階段投了贊成票就得在它上面加獨占鎖，其他事務(wù)不得接
入，直到當前事務(wù)提交or回滾。
參考文獻
- 淺析數(shù)據(jù)一致性 http://www.importnew.com/20633.html
- CAP理論 http://blog.csdn.net/chen77716/article/details/30635543
- CAP Confusion: Problems with ‘partition tolerance’ https://blog.cloudera.com/blog/2010/04/cap-confusion-problems-with-partition-tolerance/
