在做分布式系統開發時，我們經常會或多或少的聽到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、 縮短資料一致性恢復的時間，也就是如果出現資料不一致的問題，系統可以想辦法縮短恢復資料的耗時，如果當請求再次進來時，如果資料已經恢復完成，那么對于外界來說，就不會感知到此次的不一致，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/242777.html
標籤：架構設計