CAP理論以及服務注冊與發現

CAP理論是分布式架構中重要理論

一緻性(Consistency) (所有節點在同一時間具有相同的資料)

可用性(Availability) (保證每個請求不管成功或者失敗都有響應)

分隔容忍(Partition tolerance) (系統中任意資訊的丢失或失敗不會影響系統的繼續運作)

關于P的了解，我覺得是在整個系統中某個部分，挂掉了，或者當機了，并不影響整個系統的運作或者說使用，而可用性是，某個系統的某個節點挂了，但是并不影響系統的接受或者送出請求，CAP 不可能都取，隻能取其中2個

原因是如果C是第一需求的話，那麼會影響A的性能，因為要資料同步，不然請求結果會有差異，但是資料同步會消耗時間，期間可用性就會降低。如果A是第一需求，那麼隻要有一個服務在，就能正常接受請求，但是對與傳回結果變不能保證，原因是，在分布式部署的時候，資料一緻的過程不可能想切線路那麼快。再如果，同僚滿足一緻性和可用性，那麼分區容錯就很難保證了，也就是單點，也是分布式的基本核心，好了，明白這些理論，就可以在相應的場景選取服務注冊與發現了

當向注冊中心查詢服務清單時，我們可以容忍注冊中心傳回的是幾分鐘以前的注冊資訊，但不能接受服務直接down掉不可用。也就是說，服務注冊功能對可用性的要求要高于一緻性。但是zk會出現這樣一種情況，當master節點因為網絡故障與其他節點失去聯系時，剩餘節點會重新進行leader選舉。問題在于，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk叢集都是不可用的，這就導緻在選舉期間注冊服務癱瘓。在雲部署的環境下，因網絡問題使得zk叢集失去master節點是較大機率會發生的事，雖然服務能夠最終恢複，但是漫長的選舉時間導緻的注冊長期不可用是不能容忍的。

Eureka看明白了這一點，是以在設計時就優先保證可用性。Eureka各個節點都是平等的，幾個節點挂掉不會影響正常節點的工作，剩餘的節點依然可以提供注冊和查詢服務。而Eureka的用戶端在向某個Eureka注冊或時如果發現連接配接失敗，則會自動切換至其它節點，隻要有一台Eureka還在，就能保證注冊服務可用(保證可用性)，隻不過查到的資訊可能不是最新的(不保證強一緻性)。除此之外，Eureka還有一種自我保護機制，如果在15分鐘内超過85%的節點都沒有正常的心跳，那麼Eureka就認為用戶端與注冊中心出現了網絡故障，此時會出現以下幾種情況： 

1. Eureka不再從注冊清單中移除因為長時間沒收到心跳而應該過期的服務 

2. Eureka仍然能夠接受新服務的注冊和查詢請求，但是不會被同步到其它節點上(即保證目前節點依然可用) 

3. 當網絡穩定時，目前執行個體新的注冊資訊會被同步到其它節點中

是以， Eureka可以很好的應對因網絡故障導緻部分節點失去聯系的情況，而不會像zookeeper那樣使整個注冊服務癱瘓。

Consul 保證CA

也能提供較高的可用性，并能 k-v store 服務保證一緻性  CA 類型的場景 

etcd比Zookeeper是比更好的選擇，因為它很簡單，然而，它需要搭配一些第三方工具才可以提供服務發現功能。

簡單說下為什麼cap 不能同時保證

一下是在知乎上抄的一段話，簡單通俗易懂

一個分布式系統裡面，節點組成的網絡本來應該是連通的。然而可能因為一些故障，使得有些節點之間不連通了，整個網絡就分成了幾塊區域。資料就散布在了這些不連通的區域中。這就叫分區。

當你一個資料項隻在一個節點中儲存，那麼分區出現後，和這個節點不連通的部分就通路不到這個資料了。這時分區就是無法容忍的。

提高分區容忍性的辦法就是一個資料項複制到多個節點上，那麼出現分區之後，這一資料項就可能分布到各個區裡。容忍性就提高了。

然而，要把資料複制到多個節點，就會帶來一緻性的問題，就是多個節點上面的資料可能是不一緻的。要保證一緻，每次寫操作就都要等待全部節點寫成功，而這等待又會帶來可用性的問題。

總的來說就是，資料存在的節點越多，分區容忍性越高，但要複制更新的資料就越多，一緻性就越難保證。為了保證一緻性，更新所有節點資料所需要的時間就越長，可用性就會降低。

本文轉自wks9751CTO部落格，原文連結：http://blog.51cto.com/wks97/2064702 ，如需轉載請自行聯系原作者