問題之由來
我第一次聽說mongodb、hbase這些分佈式數據庫的時候，正是我學習mysql的時候，在那個遙遠的年代，mysql可是java web項目的標配，恰如今日hadoop之於大數據。高可用、彈性擴展，分佈式數據庫帶來了種種眼花繚亂令人目眩的特性，深深吸引着當時涉世未深而又孤陋寡聞的我，然而零基礎轉行大數據又處處碰壁，屢戰屢敗之後，纔有一個大數據項目組給了一個降薪的offer讓去給他們做前端。
囊中羞澀前途未卜，應該接受這個降薪的offer麼？幾乎毫不猶豫的，我開始了flash開發之旅。
學習大數據時，CAP定理是我最早接觸的概念，在一段時間裏，它對我一直都是金科玉律，每看到一個系統，我都會推斷它到底是AP的還是CP的，直到我最近突然想到一個問題：
一直都說zookeeper是強一致性的(實際上，zookeeper的一致性是Sequential consistency，等有機會了再講)，mongodb的replica set也可以設置爲強一致性，但是它們又能通過leader選舉等方法保證高可用，那麼豈不是說zookeeper和mongodb完全滿足了CAP的三個特性？
一時間雲波詭譎撲朔迷離，於是我決定重新審視一下CAP定理。
CAP定理的來龍去脈
CAP定理（CAP theorem）既然叫做“定理”而不是公理或者猜想，那就說明它是可以被證明的。現在比較流行的說法是，Brewer最早做出了推測，而Seth Gilbert和Nancy Lynch在《Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services》中做出了證明。
zookeeper、mongodb和CAP的A
在證明裏，A是被定義爲every request received by a non-failing node in the system must result in a response。總體來說，定義過於簡潔，理解過於多樣。
- 比如，在mongodb裏，使用它的客戶端以後，所有的寫請求都發給了primary，但是假如我能把一個寫請求直接發給secondary，它會怎麼處理？如果secondary返回了一個錯誤，說“喂，我們secondary不接受寫請求”，這種情況算不算它“result in a response”？
- 再比如，如果發生網絡隔離，一臺被孤立的zookeeper服務器就變成了looking狀態，把一個讀或者寫請求發給了它，它返回一個錯誤，說“我已經六神無主了，你還是找別人吧”，這種情況算不算它“result in a response”？
如果這些都不算的話，那麼zookeeper和mongodb replica set都不滿足CAP的A，但是它們又都是高可用的，因爲上述情況下，client都能正確處理，應用程序都能正常運行。
關於CAP中A的正確理解，還敬請持續關注這個問題。
CAP定理的嚴格證明
CAP定理正確不正確呢？在我看來，從公理上來看是顯而易見的，從定理上來看是曖昧不明的。
爲了讀懂《Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services》，我先找了Lynch阿姨的《Distributed Algorithms》看了兩天，然而發現異步網絡的定理1還算合理，然而推論1.1就雲山霧罩，半同步網絡的定理2更是不知所云。實在才疏學淺，所以這個問題也forward給其他大神了，期待更好的回答。
同時，外國幾位老哥也對CAP定理的證明存在着質疑，大家有興趣可以圍觀一下。
https://maniagnosis.crsr.net/2010/09/some-misconceptions-about-cap-theorem.html
http://markburgess.org/blog_cap.html
參考資料
《Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services》
《Distributed Algorithms》