在做分散式系統開發時，我們經常會或多或少的聽到CAP理論、或者是處理節點間資料一致性的問題。
但CAP理論究竟是什麼呢？
CAP理論很簡單，但卻是很多軟體設計的巨集觀指導，因此也有人將之稱為架構師必須掌握的理論之一。
鑑於理論的東西相對來說比較抽象而且繁瑣，因此我們先舉個例子：
有一天你打王者榮耀連跪，於是找了一個大神魯班，帶你起飛：
於是就發生了下邊的對話
（1）
射手魯班：救救我，謝謝
輔助蔡文姬：收到
（2）
輔助蔡文姬：我來抓人了
射手魯班：收到
如果一切良好，那麼一切都OK
但是假若這時候YY語音突然掛掉了
（1）射手魯班：救救我，謝謝
蔡文姬，沒有響應
（2）輔助蔡文姬：我來抓人了
射手魯班，沒有響應
那麼接下來有兩種策略：
1、 暫時先不管YY語音的問題，繼續打好遊戲。
2、先不打遊戲了，切屏打電話給對方，看下是不是發生了什麼狀況
是的，這涉及到所謂的CAP理論了，
也就是在分散式場景下，如果不同節點之間的通訊出現了問題，那麼不同節點的響應策略應該是什麼樣的。是該暫停響應，等待連線恢復，還是應該堅持響應，忽略資料的不一致性。
我們先來看下計算機領域中，CAP的專業解釋：
一致性 Consistency：在分散式系統中，所有的資料備份，在任意時刻都要求一致；
可用性 Availability：對於分散式系統中的節點，在任意時候都可以正常的進行讀寫響應，並且不超時；
分割槽容錯性 Partition tolerance：當節點之間的通訊出現(防盜連線：本文首發自http://www.cnblogs.com/jilodream/ )故障時，整個分散式系統仍然可以執行起來，不至於直接崩潰掉；
P是背景，也就是在分散式系統下，如果節點之間的通訊出現了問題，那麼整個系統仍然在執行，等待網路恢復後，整個系統仍然可以正常操作。
經過理論以及實際的推演，我們發現在P的背景下，AC不可以共存。
也就是你無法做到既保證了節點的可用性，還保證了一致性。
專業的推演證明，這裡就不說了，筆者自己的理解是這樣的：
當節點之間的網路崩潰時，節點如果想要能夠支援可用性，勢必會造成資料的修改，從而造成資料的不一致，而網路又崩潰掉，因此沒有辦法進行節點間的資料同步。現在對於接下來的處理策略有兩個選擇：
（1）如果節點想要支援一致性呢，那麼唯一的選擇就是不能進行資料的寫，這是因為節點之間無法進行資料的同步，因此只能放棄寫操作，這就導致失去了高可用性。
（2）如果支援了寫，那麼就會出現節點間的資料不一致，並且由於網路問題，無法及時同步，這就失去了高一直性。
這套理論有什麼用呢？
他可以明確指出，對於分散式系統來說，無法做出資料完美一直，而且有高可用的場景。架構設計必須要做出取捨。
1、遵從可用性，放棄高一致性
2、支援高一直性，放棄高可用性
具體應該如何選擇，由業務來決定。如果你的系統支援短暫的業務停頓，但是系統不能出錯，那麼就要傾向於CP方案，如實時通話系統，財務交易系統。如果你的系統支援暫時的資料不一致性，但是一定要保證高可用性，如直播點贊，評論。那麼就要傾向於AP方案。無所謂哪種方案更優秀，而是需要由業務來驅動技術的選型。
很多人說，不是CAP，三者取其二麼？為什麼你這裡只有CP，和AP?
這兩種理解其實都可以，但是（注意，要畫重點了）
P所代表的是分割槽容忍性，是指分散式場景下，對於網路通訊問題下仍然可用，這個是前提。
CP和AP是基於這個前提討論的兩種方案。如果劃掉P，取AC，也就是單機場景下的一致性和可用性(防盜連線：本文首發自http://www.cnblogs.com/jilodream/ )問題，這就失去了討論的意義。這好比在中學物理中R=U/I ,電阻等於電壓除以電流。但是你不能理解為電阻與電壓成正比，與電流成反比，因為電阻只與材料和規格相關。你可以按照公式推算出資料，但是不代表是字面的含義。
另外需要注意的是，上述情況下，都是理論模型，其中忽略了資料一致性所需要的網路延遲。也就是說，在實際情況中，由於網路的延時問題，高效的CP系統非常難實現。同時又由於網際網路產品中本身需要的快速響應，所以在實際的開發中，往往AP模式的設計，相對來說佔比會更大一點。那麼如何規避掉資料不一致性造成的影響呢？
這裡提供兩個思路
1、 資料的最終一致性，出現一致性問題沒關係，只要不影響到核心的資料計算，是可以接受的。只要最終的資料能夠保證一致性，滿足冪等性即可。
2、 縮短資料一致性恢復的時間，也就是如果出現資料不一致的問題，系統可以想辦法縮短恢復資料的耗時，如果當請求再次進來時，如果資料已經恢復完成，那麼對於外界來說，就不會感知到此次的不一致。