走進cassandra 之一 CAP和分佈式

決定share一下個人cassandra學習成果，寫一些博客，跟你們共同分享一下，準備寫10篇文章，內容分別涉及

分佈式存儲概述及CAP,
數據模型,
分區器，
副本機制，
存儲機制，
數據讀寫刪，
最終一致性，
gossip,
cassandra的實際應用，
學習總結。

先寫第一篇，先說咋理解分佈式。

這術語解釋起來拗口，舉個例子就比較好理解了。
好比說參與cloudtask這個項目的人，有好幾撥，有王薇 team，有徐超 team， 有韶涵 team， 有田萌 team, 有紅豔 team.
爲啥分紅幾撥人來作呢？
爲啥不是james大俠（CTO）一力承擔？

由於james智慧再高超，本領再強大，也沒有辦法一我的處理全部事情。
計算機裏有兩個詞，一個叫縱向擴展，一個叫橫向擴展，james加班加點看代碼，這個是縱向擴展，這個擴展是有限的，擴展到24個小時，就到頭了。
由於此，較爲可行的辦法是橫向擴展，就是如前所說的，分紅幾撥人來作，這就是分佈式了。

分佈式的優勢是大大的，最明顯的就是能夠同時處理不少事情，能夠同時響應不少請求。
分佈式萬歲！

且慢！
啥東西也不是光有優勢，分佈式的缺點也是大大的。
這缺點，其實很容易想到，剛纔的例子中，工做分了幾撥人來作，每人都是James嗎？ ＮＯ。每人都會有本身的認知，每人的認知都不一樣，分紅５波人來作，５波人就有５個認知，因此要怎麼辦呢？

溝通。

須要花費很多時間精力來溝通，這就是分佈式的缺點。

溝通到你們認識在一個水平，這叫同步。
溝通的時候有部分人沒有徹底理解，這叫信號丟失。
溝通的時候，發現開發組和測試組思路徹底不同，這就等同於倆數據中心。

如上所述，分佈式的優勢大大的，缺點也是大大的，下面就是你如何取捨了。
想要魚仍是想要熊掌。

爲了讓你取捨有個標準，有位大師研究出一個理論，ＣＡＰ理論。

這位大師就是EricBrewer教授，他提出,在設計和部署分佈式應用的時候,存在三個核心的系統需求：

C: Consistency 一致性

A: Availability 可用性

P:Partition Tolerance分區容錯性

CAP理論的核心是：一個分佈式系統不可能同時很好的知足一致性，可用性和分區容錯性這三個需求，最多隻能同時較好的知足兩個。

總而言之，三個只能取其二。

對應的業界的名言就是　一個軟件，能夠很好，也能夠很快，也能夠很便宜，可是這三個，你永遠只能要求兩個。

那麼ＣＡＰ究竟是咋個回事呢？
● 一致性（C）：在分佈式系統中的全部數據備份，在同一時刻是否一樣的值。
● 可用性（A）：在集羣中一部分節點故障後，集羣總體是否還能響應客戶端的讀寫請求。（可用性不只包括讀，還有寫）
● 分區容忍性（P）：集羣中的某些節點在沒法聯繫後，集羣總體是否還能繼續進行服務.
對比咱們上面的例子，好比james寫了一個push的需求，你無論去問王薇仍是韶涵，結果必須是同樣的。
可用性就是，即便今天徐超請假了，工做仍不能耽誤，項目繼續進行。
分區容忍性，典型的例子就是，若是中美之間海底電纜斷了，北京和總部已經不能溝通，你這項目還能繼續往下作。
就像咱們說過的，這三個特性，你只能要倆。

在數據庫的世界裏面，關係型數據庫講究的是 ACID，什麼意思呢？
原子性(Atomicity).
事務中的全部操做,要麼所有成功,要麼所有不作.
一致性(Consistency)
在事務開始與結束時,數據庫處於一致狀態.
隔離性(Isolation).
事務如同只有這一個操做在被數據庫所執行同樣.
持久性(Durability).
在事務結束時,此操做將不可逆轉.

在分佈式領域，有一個對應的模型叫 BASE.

Basically Available（基本可用）
Soft state（柔性狀態）
狀態能夠有一段時間不一樣步，異步
Eventually consistent（最終一致）
最終數據是一致的就能夠了，而不是時時一致

咱們使用的 MySQL, 遵循的是 ACID， 如今使用的  cassandra,遵循的是BASE。 BASE的基礎，就是CAP理論。 cassandra在CAP裏面，取的是AP，舍的是C，注意：並非徹底不要C，而是要了一個弱化的C。 也就是最終一致，不是時時一致。