沒人能擋得住你瘋狂的努力進取！
CAP理論概述
CAP是分散式架構中一個非常重要的理論。內容如下：
任何一個分散式系統最多隻能同時滿足一致性（Consistency）、可用性（Availability）和分割槽容錯性（Partition tolerance）這三項中的兩項。
一致性，“all nodes see the same data at the same time ”，所有節點在同一時間內資料一致。比如在高併發的分散式系統中，更新操作如何確保分割槽一致。如何確保相同的請求返回的資料一致！
可用性，“Reads and writes always succeed“，服務永遠能進行讀寫，一個正常執行的節點必須能夠對每一個請求作出反應。
分割槽容錯，“the system continues to operate despite arbitrary message loss or failure of part of the system“ ，當系統中某一節點宕機之後，其他節點依然能夠提供基於CA的服務！
CAP理論經典應用
在CAP理論中，我們無法同時滿足資料一致我，高可用性和分割槽容錯性，那麼在現實的開發中，我們應該如何取捨？首先在分散式系統中，網路分割槽成為伺服器叢集部署，容災的首選，像京東，微信淘寶等超級大型分散式框裡P是必須要滿足的，不能把所有的伺服器都部署在同一個機房，哪天機房網路出現故障，會影響整個系統的可用性和一致性！所以下來只談談CP和AP。
CP，如果一個分散式系統能夠容忍服務在一定時間不可用，不要求嚴格時時可用，那麼可以選擇CP選擇，我們開發中經常接觸到的zookeeper就是CP的經典使用範例。zookeeper基於它的選舉策略，當master不可訪問是，所有slave會自動重新選舉，選擇一個新的master出來，在選舉期間，服務是不可用的。當然還有很多要求資料強一致性的都選擇滿足CP，比如Hbase，redis等。
AP，如果一個系統，要高可用並允許分割槽，則需放棄一致性。一旦網路問題發生，節點之間可能會失去聯絡。為了保證高可用，需要在使用者訪問時可以馬上得到返回，則每個節點只能用本地資料提供服務，而這樣會導致全域性資料的不一致性。這種捨棄強一致性而保證系統的分割槽容錯性和可用性的場景和案例非常多。前面我們介紹可用性的時候說到過，很多系統在可用性方面會做很多事情來保證系統的全年可用性可以達到N個9，所以，對於很多業務系統來說，比如淘寶的購物，12306的買票。都是在可用性和一致性之間捨棄了一致性而選擇可用性，再比如現在特別火的spring-cloud中eureka，也是一個高可用的框架，透過偽去中心化的方式每個節點都快取所有節點資訊，即使eureka-server宕機，eureka-client也可以透過本地快取的節點資訊進行排程。這也是
eureka
和
zookeeper
分散式框架最重要的區別之一。
BASE理論
BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的縮寫。權衡CAP中強一致性和高可用，提出BASE理論。
Basically Available（基本可用）：基本可用是指分散式系統在出現不可預知故障的時候，允許損失部分可用，當然前提是系統依然可用。比如我們經常提到的服務降級，肖峰等。
Soft state（軟狀態）：軟狀態指允許系統中的資料存在中間狀態，並認為該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的資料副本之間進行資料同步的過程存在延時。這個在資料一致性的考慮中尤為重要。
Eventually consistent（最終一致性）：比如轉賬匯款就是經典的最終一致性。
我是程式設計師大狂客，分享讓知識無界！
