什麼是CAP定理?

　　張大胖在公司奮發圖強，通過多年的努力，終於作到了架構師的位置。架構師的椅子還沒坐熱，很快就來了一個項目要作架構設計。老闆把大胖叫來，諄諄教導說： 大胖啊， 數據是咱們的寶貴資產，你設計的系統可千萬要保證數據不能丟失啊！大胖說老闆放心， 這方面我有經驗， 通常來說咱們要作數據的冗餘處理， 簡單的來說就是給數據作多個副原本保存。 我會設計一個分佈式系統， 把數據備份到多個機器節點去。

　　幾天後， 大胖給發了一張圖， 展現了這個分佈式系統是怎麼工做的：

　　數據副本在不一樣的機器上作冗餘， 中間有數據的複製， 保證數據的同步。雖然只是兩臺機器， 可是也構成了一個簡單的分佈式環境。老闆雖然不懂技術， 可是看到數據在不一樣的機器之間有備份，也就放心了。通過幾個月的開發和測試，系統順利上線， 可是你們很快就發現：  分佈式系統不像單機系統那麼簡單， 因爲網絡的緣由， 或者某個機器的緣由很容易致使通信失敗，或者節點不可用。

　　有一天， 用戶先訪問了左邊的機器A , 寫入了一條數據，  而後機器A很不幸， 網線被悲催的網管給踢掉了， 這直接致使了兩個嚴重的後果：

　　　　1. 負載均衡找不着機器A，認爲它死翹翹了， 就要把用戶的下一次訪問轉到機器B去。

　　　　2. 數據複製也找不着機器A  ,  只好罷工。 用戶剛寫入的數據無法複製到機器B，機器B上仍是老數據

　　怎麼辦？

　　雖然這是一次偶然， 把網管臭罵一頓， 插上網線就能夠了， 可是誰能保證之後兩個機器的通訊是一致暢通的呢？

　　組裏的小王說：    咱們的機器B 還活着呢， 還能提供服務， 數據複製不到機器B， 不就是少看幾條數據嘛， 無傷大雅，不影響大局， 勉強可用， 插上網線後數據複製就會工做， 一切就會恢復正常。

　　小王無心中選擇了系統的可用性(Availability，簡稱A)， 系統能提供服務就好， 數據不一致能夠忍受。

　　張大胖說:  不行，  老闆說了，咱們系統的數據極爲重要， 數據若是不一致會帶來嚴重後果，因此機器B上的和這些關鍵數據相關的功能也必須停掉， 必須等到機器A插上網線，數據同步之後才能開工.很明顯， 張大胖遵循老闆指示， 把一致性（Consistency, 簡稱C ）放到了首位。

　　因此問題就很明顯了， 在網絡節點之間沒法通訊的狀況下,  和數據複製相關的功能， 要麼選擇可用性(A) , 要麼選擇一致性(C)， 不能同時選擇二者。

　　大胖仔細思考了一下， 其實這兩種選擇的背後其實隱藏着另一個事實， 那就是網絡節點之間沒法通訊的狀況下， 節點被隔離，產生了網絡分區，  整個系統仍然是能夠工做的， 大胖給它起了個名： 分區容錯性（Partition tolerance， 簡稱P）。

　　若是選擇了可用性(A) + 分區容錯性(P) ,  就要放棄一致性(C)。

　　若是選在一致性(C) + 分區容錯性(P) , 就得放棄可用性(A)  ，   對了， 這種狀況下，雖然系統的有些功能是不能使用的， 由於須要等待數據的同步， 可是那些和數據同步無關的功能仍是能夠訪問的 ， 至關於系統作了功能的降級。

　　既然有AP和CP,    會不會出現僅僅是CA（一致性+可用性）這種組合呢？ 就是沒有分區容錯性， 只保留可用性和一致性？ 仔細想一想， 這種狀況其實就退化成了單機應用， 沒有意義了。

　　大胖以爲本身彷佛發現了一個規律：   在一個分佈式計算機系統中，一致性(C)，可用性(A)和分區容錯性(P) 這三種保證沒法同時獲得知足，最多知足兩個。

　　他決定把找個規律叫作CAP定理， 聽起來比較高大上， 顯得本身高深莫測。

　　若是你實在是搞不懂這CAP,   張大胖會告訴你一個更容易理解的版本： 在一個分佈式系統中， 在出現節點之間沒法通訊（網絡分區產生）， 你只能選擇 可用性 或者 一致性，  無法同時選擇他們。

轉載自公衆號  碼農翻身