1. 程式人生 > >看起來很唬人,然而卻簡單實用的CAP理論

看起來很唬人,然而卻簡單實用的CAP理論

在做分散式系統開發時,我們經常會或多或少的聽到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、 縮短資料一致性恢復的時間,也就是如果出現數據不一致的問題,系統可以想辦法縮短恢復資料的耗時,如果當請求再次進來時,如果資料已經恢復完成,那麼對於外界來說,就不會感知到此次的不一致。

&n