以故事形式描述分佈式概念中的CAP理論

在看微服務的時候看到不少關於CAP的講解，可是感受都比較理論，不夠通俗，看到下面這個以故事形容CAP理論講的很是好，作個記錄

CAP原則。你們都很是清晰的知道：任何的分佈式系統，在可用性、一致性和分區容錯性方面，是不可兼得的，就像是咱們常說的「魚和熊掌不可兼得」同樣，最多值能得其二。因此說，任何一個分佈式系統的設計，都是根據各自的實際應用場景和需求，對這三個維度的的不一樣取捨而已。

CAP原則又稱CAP定理，指的是在一個分佈式系統中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。換句話說，就是說在一個系統中對某個數據不存在一個算法同時知足 Consistency, Availability, Partition-tolerance。

● 一致性（C）：在分佈式系統中的全部數據備份，在同一時刻是否一樣的值。一致性被稱爲原子對象，任何的讀寫都應該看起來是「原子「的，或串行的。（等同於全部節點訪問同一份最新的數據副本）
● 可用性（A）：在集羣中一部分節點故障後，集羣總體是否還能響應客戶端的讀寫請求。（對數據更新具有高可用性）
● 分區容錯性（P）：以實際效果而言，分區至關於對通訊的時限要求。系統若是不能在時限內達成數據一致性，就意味着發生了分區的狀況，必須就當前操做在C和A之間作出選擇。

故事下面正式開始：

第一集：商機無處不在——A君的「記憶公司」初誕生！

單體應用的單身

從前有個A君，他好像天生記憶力就特別好。俗話說，健忘是男人的通病，但A君不同，大到結婚記念日、老婆大人生日，小到「兩人第一次約會記念日」，「家裏的寵物汪生日」，他都能如數家珍。這不，昨晚正是老婆大人生日，他即時送驚喜，哄得老婆大人忒開心。「個人記憶力咋就這麼贊呢？」他一陣陶醉……忽然，一道靈光閃過，「何不開個公司好好利用這天賦來賺錢？！」並且新公司的廣告能夠這麼打：

A君說作就作，他的「記憶公司」就這樣開張了，員工規模嘛，一我的——他本身。
「記憶公司」的平常業務通話是這樣的：
顧客：你好，我想存下我老丈人的生日。
A君：請問是何時？
顧客：1月2日。
A君：（在筆記本上記下後）當你須要用到它時，歡迎隨時致電咱們。
顧客：很是感謝。

第二集：是時候擴大規模了！

分佈式系統初期
因爲A君貼心的服務質量，固然還有他磁性低沉的迷人嗓音，顧客來電絡繹不絕。不久後，「記憶公司」就獲得某著名創業孵化器的大筆贊助了。你想啊，A君只須要 一個筆記本和一個電話就能開展業務，業務規模固然擴張得很迅速。不知不覺A君天天的電話業務量快破千，這下忙得他焦頭爛額。

還有更嚴重的問題來了。愈來愈多顧客打電話過來發現永遠佔線，不少人等得不耐煩就掛斷了。再加上A君最近實在太累，終於有天病倒了沒有開工，那一成天的業務就這麼泡湯了，而對於那天急需信息的顧客來講，不滿的情緒更是直線飆升。

是時候擴大公司規模了！A君馬上動員親愛的老婆大人來幫忙。

並且他設計了一個簡單的新系統：

我和老婆一人一部分機。
顧客依然撥打(888)–88-REMEM，他們只需記住這一個號碼。
經過一部PBX（電話交換機）將每一個顧客來電平等發送到我和老婆兩人中正空閒的一部分機上。

第三集：遭遇了第一次服務危機

bug初現

就在新系統上線兩天後，A君接到忠實顧客老王的電話：
老王: 喂，兄弟！
A君： 哎，老王，此次有什麼要幫忙的？
老王: 幫我查下飛東京的航班是何時。
A君： 稍等。
（他低頭查看本身的筆記本）
（牙敗！在老王的頁面居然沒有任何關於「航班日期」的記錄！！！）
A君（努力鎮定）：老王，你應該沒告訴過咱們關於你飛東京的航班信息啊！
老王（納尼？！）： 我明明昨天就打電話說過了啊！（生氣掛斷！）

這是怎麼一回事？老王在撒謊嗎？A君沉思了一秒鐘，恍然大悟！——昨天老王的電話是老婆接的——A君立刻來到老婆的書桌前翻看她的筆記本。果不其然，老王的航班信息就在上面！隨後A君把此次「老王事件」說給了老婆聽，她表示也注意到了這個問題……

A君一想到這些就抓狂。

第四集：一致性問題成功修復！

填完一個坑，解決一致性問題，出現可用性問題

自從發現了「一致性」問題後，A君整夜展轉反側，苦思冥想解決辦法。終於在一天清晨，一個絕妙的方案讓他想到了！他興奮地搖醒一旁熟睡的老婆大人，急不可耐地告訴她：

「親愛的，我想到解決辦法了！接下來咱們能夠這麼辦：」

從如今開始，咱們兩人不管誰接到顧客的電話（有信息要求咱們記錄），咱們必須通知對方本次更新信息。
咱們要在各自的筆記本上同時記錄此次更新信息，纔算這個電話close file。

當顧客致電來索要以前存放的信息時，咱們無需詢問對方，只要查看各自的筆記本就好了。由於我倆的筆記本所記載的顧客信息同一時段時刻保持着同步更新。

「好像還有一個問題！」A君忽然意識到。

「這樣一來，每次有新的顧客信息「更新」，咱們兩人都得同時作記錄，咱們就不能在並行的時間段裏接電話了！」

「並且，咱們不管什麼時候不能給顧客提供錯誤信息。」A君補充到。

「徹底贊成」，A君的老婆連連點頭，「可是這系統還有另外一個缺陷你沒注意到。若是哪天咱們當中有一個沒開工，那就意味着那天全部的‘更新電話’（即：顧客有更新信息要求記錄）咱們就沒能接到，由於沒開工的那一方沒有更新任何記錄。」也就是說，系統還存在「可用性」的問題。

第五集：最完美的解決方案誕生了！

解決可用性

A君漸漸意識到設計一個分佈式系統並無當初預想的那麼簡單。要同時兼顧「一致性」和「可用性」真的很難作到嗎？也許對別人很難，但對於天性驕傲的A君來講，他固然不服輸。
這不，幾經思索，又一個清晨，一個別人作夢都想不到的完美方案仍是讓A君想到了，他再次興沖沖搖醒身旁熟睡的老婆大人。

「看！」，A君興高采烈，「採用下面這種作法，就能同時實現‘一致性’和‘可用性’了，雖然這作法和以前的很類似」：

從如今開始，咱們兩人不管誰接到顧客的電話（有信息要求咱們記錄），若是另外一方這天處於開工狀態，咱們就通知對方本次更新信息。咱們要在各自的筆記本上同時記錄此次更新信息，纔算這個電話close file。
若是另外一方這天處於放工狀態（放假休息），咱們就發電郵通知對方本次更新信息。
次日另外一方收假回來準備開工前，首先得檢查全部電郵，把休息這天落下的顧客「更新」信息在本身的筆記本上所有補上。而後再開始這新一天的第一通顧客來電。

「親愛的，你真是個天才！」A君的老婆拍手稱快，「如今我幾乎找不出這個系統有任何缺陷了。咱們立刻開始吧！」因而從這天起，「記憶公司」就能同時作到「一致性」和「可用性」了。

第六集：老婆大人在生氣！

分區容錯性問題出現

一切進行得很順利。A君的分佈式系統不只完美展現着「一致性」，並且即便哪天他們兩人中有一個放假休息，公司運做絲毫無影響。可是有天老婆大人生氣了！即便兩人都在開工，她接到了顧客要求記錄信息的電話，卻由於生悶氣，決定這一天都不告訴A君「更新「信息。這下完蛋了！到目前爲止，一直保持「一致性」和「可用性」的完美系統卻由於沒有「分區容錯性」瞬間崩潰！因而A君決定哄好老婆大人以前，他本身這邊不接任何顧客電話，因而在這段時間內，整個系統是失去「可用性」保障的。

第七集：總結的時間到了

如今讓咱們看回CAP理論，它主要是講，在設計一個分佈式系統時，沒法同時兼顧「一致性」、「可用性」和「分區容錯性」，你只能選擇成全其中的兩個：

一致性：顧客一旦致電過來，要求記錄他的最新信息，那麼在他下次索要信息時，都必須第一時間將最新信息準確告訴他，不管顧客回電間隔多麼短。

可用性：「記憶公司」一直保持良好的業務運做，即便哪天A君和他老婆中有一個放假休息。

分區容錯性：「記憶公司」一直保持良好的業務運做，即便哪天A君和他老婆之間發生冷戰，一段時間內拒絕溝通。

最後的彩蛋：招一個跑腿小弟入夥，實現終極「一致性」

若是招一個跑腿小弟入夥，當A君和他老婆其中一方的筆記本有「更新」時，這位小弟能夠幫忙跑腿，迅速將他們夫妻中另外一方的筆記本同步更新。這樣作最大的好處是，他是在後臺跑腿，因而接到「更新電話」的一方只要在前端繼續進行他的業務便可，無需像以前那樣，可能得停下來等待另外一方趕來和他「同步」更新筆記本。

不少NoSql系統就是這樣工做的，一個節點在本地更新，後端進程將其更新信息同步更新到全部其它節點。惟一的問題是，某些時候系統的「一致性」將得不到保障。

例如，當老婆接到一個顧客電話要求記錄信息時，跑腿小弟還沒來得及跑過來同步更新A君的筆記本，該顧客一個電話打到A君這裏來了，這時他固然不可能獲得想要的最新信息……但若是這種狀況只是小几率事件的話，招跑腿小弟入夥的想法仍是很贊很讚的。你想啊，顧客的記性不會差到前腳「要求記錄信息」的電話剛掛斷，5分鐘後就回電詢問「剛記錄的信息是什麼」吧？！

再次致敬原做者，太厲害了，通俗易懂
原文地址：http://www.sohu.com/a/7743039...