CAP 理論 —最通俗易懂的解釋
CAP 理論是分散式系統的一個基礎理論，它描述了任何一個分散式系統最多隻能滿足以下三個特性中的兩個：
1：一致性（Consistency）
2：可用性（Availability）
3：分割槽容錯性（Partition tolerance）
CAP 理論聽起來十分抽象，本文嘗試以生活中的例子並用通俗易懂的語言來解釋 CAP 理論的含義。
第一章：記憶公司面世
一天晚上，正準備入睡時，你的妻子對你記住她生日並送她禮物表示感謝。這時，一個商業想法從你的腦海中閃現：人們總是弱於記憶生活中的事情，而我卻擁有超群的記憶力，因此，為何不成立一間公司可以充分運用自己的記憶天賦來賺錢。說幹就幹，接著你在當地一間報社刊登了記憶公司的宣傳廣告：
記憶公司 —— 你的事情永不會忘記
還在為你老是忘記而苦惱？福音來了，只須一個電話。
當你需要記著某件事情時，請撥打 400 - 888 - 8888，告訴我們你需要記住的事情，下次你需要找回這件事情，請再次撥打電話，我們將會告訴你的所需。
收費： 每次只需要 10 元。
以下是一次你和顧客的電話對話。
顧客：Hey，麻煩幫我記住我鄰居的生日。
你：好。你鄰居生日是什麼時候？
顧客：1月2日。
你：（在一個本子，翻到這位顧客的一頁，記錄下他鄰居的生日。）好的，已記錄好。下次你找回鄰居的生日，請再次撥打電話。
顧客：謝謝。
你：不客氣，本次收費 10 元。
第二章：業務擴大了
隨著時間的推移，記憶公司的業務發展得越來越好，越來越多的顧客打電話進來需要服務。雖然賺到的錢越來越多，但也產生了一個新的問題。 顧客打電話進來時，需要等待的時間越來越多，另外，當你生病時，所有顧客都不能獲得服務，這令人很是煩惱。
於是，你想出了一個新的計劃：你和你的妻子同時接收顧客的電話，顧客仍然只需要記著一個公司的服務電話 400 - 888 - 8888，一個路由器會將顧客的電話分發到你和妻子電話上
第三章：服務出錯了
新計劃實施兩天後，你接到了一個名叫 John 的電話，John 是個老顧客了。
John：Hey
你：你好，歡迎撥打記憶公司電話，有什麼可以幫到你嗎
John：可以告訴我去新澤西的航班是什麼時候嗎
你：當然。（然後你翻開 John 的頁面，發現並沒有 John 航班的記錄）
你：你好，是不是搞錯了，我們這裡並沒有關於你航班的資訊
John：什麼？！昨天我才剛打電話過來說去新澤西航班的事情
哪裡出錯了？難道 John 撒謊了。你繼續思考導致出錯的原因。會不會是妻子接到了電話？你走到妻子的桌子，發現妻子將 John 的航班記錄在了本子上，這時你才意識到導致問題的原因，妻子接聽到 John 的電話，但你的本子沒有 John 的記錄。
如果將上面的實施計劃稱一個分散式的設計，那這個設計存在明顯的問題——一致性（consistent）的問題。打進來的電話可能其中一人接聽並記錄下來，下次電話查詢時卻可能由另一人接聽，這樣就會出現不一致的問題，無法為顧客準確提供服務。
第四章：解決一致性問題
晚上你在床上翻來覆去，最後想到一個解決一致性問題的辦法，你把新的計劃告訴妻子：
每次接收記錄的電話（顧客要求幫忙記住他們的事情）時，我們同時告知另一個人
這樣，我們兩個人都會在本子更新這位顧客的記錄
下次這位顧客再次打電話進來查詢，這時我們不需要告知對方，因為兩個本子都有這位顧客的記錄了
這個方法只有一個問題，你告訴妻子，當有顧客需要記錄時，我們不能並行地工作。例如，你接收到記錄的電話並這個資訊告知我，這時我就不能再接聽其他顧客的電話了。但這個問題基本上也是可以接受的，因為大部分顧客的電話都是查詢的。
老公你真聰明，妻子稱讚你，但這個設計還有一個問題。如果某天我們其中一個人有事不能工作了怎麼辦？由於我們要求每次接到記錄電話需要同時更新兩個本子，這就導致我們不能為顧客提供記錄的服務，這樣就導致無法滿足 可用性（availability）的要求。例如，當我接到一個記錄的電話時，而你恰好不在，這樣我就無法完成這個顧客的服務。這是由於我無法要求你更新你的本子。
第五章：更好的辦法
這時你才意識到，設計一個分散式的系統是多麼的不容易，難道就沒有同時滿足 一致性和可用性 的設計嗎？
又經過一晚的思考，你想到一個兩全其美的辦法，新的辦法跟之前的很相似。你把新的辦法告訴妻子：
當接到記錄的電話（顧客要求為他們記錄事情），如果我們兩人當天都上班，那麼我們同時記錄下這位顧客的記錄
但如果另一人當天沒上班，我們可以將記錄通過 E-mail 的方式傳送給不上班的人
第二天，沒上班的人上班後第一件事就是接收所有的 E-mail ，並在自己的本子上記錄所有顧客的要求。記錄好後，才開始接收第一個電話。
真是天才，妻子說，這個辦法我找不出任何問題了，而且可以同時滿足 一致性和可用性 的要求。
第六章：妻子生氣了
公司所有業務繼續正常運作了好一段時間，即使你和妻子其中一人不上班，服務仍然可以正常提供。
好景不長，新的問題又出現了。
一天，妻子由於某件小事對你很是生氣，以至於她接到一位顧客需要記錄的電話並沒告知你。由於記錄沒能在兩個本子更新，你的設計完全被打破了。你的設計建立在兩人良好溝通的前提下，如果出現溝通無法進行的情況，系統就出現問題了。也就是說，你的設計沒有達到 分割槽容忍性（partition tolerant）的要求。
當然，你也可以允許溝通無法進行的情況下繼續提供服務。這樣，當有顧客需要記錄時，由於需要滿足 一致性 要求，這位顧客的服務就無法完成，也就是 可用性 無法滿足。。。
第七章：結論
讓我們再次回到 CAP 理論，CAP 理論告訴我們，當設計一個分散式系統時，我們無法同時滿足 一致性，可用性，分割槽容忍性 的要求，我們最多滿足其中的兩個要求，形式化的證明，可以參考 CAP 理論的證明 。
一致性：一旦顧客更新了記錄，下次再打電話查詢時，總能獲取最新的記錄
可用性：只要你和妻子有人上班，記憶公司總能為顧客提供服務
分割槽容忍性：即使你和妻子的溝通無法進行，記憶公司仍然可以提供服務
番外篇：背後的記錄員
上面設計的系統仍然有優化的空間。記憶公司可以僱傭一個記錄員，當你和妻子其中一人接到顧客的記錄電話時，記錄員在背後會將這個記錄寫在另一個人的本子上。這樣一來，另一個人的服務就不會被這個記錄的電話打斷。許多 NoSQL 系統就使用了這個方法，一個節點更新了資料，背後會有一個程序將資料同步到其他節點。
這種設計存在的問題是可能在短時間內丟失一致性。例如，顧客打電話進來要求記錄，妻子接聽到這個電話。緊接著，這位顧客再次打電話進來要求查詢，你接聽到這個查詢的電話。如果記錄員還沒將這位顧客的記錄更新到你的本子，這時顧客就沒法正常查詢。雖然存在這種可能性，但你也不用過分擔心，因為顧客很少會打完記錄電話後馬上又打查詢電話，所以出現本子內容不一致的概率很低。
原文釋出時間為：2018-09-21
原文作者：haozlee
本文來自雲棲社群合作伙伴“ ofollow,noindex">Python專欄 ”，瞭解相關資訊可以關注“ Python專欄 ”。