最近有時間研究分佈式架構，因爲公司使用的Zookeeper，並沒有使用Spring Cloud Eureka，所以想探究一下他們之間的區別，於是看到簡書裏的文章：Spring Cloud Eureka簡介及與Zookeeper對比，明顯的區別可能就是Zookeeper爲CP設計，而Eureka爲AP設計，但是對CAP/AP/CP很不理解，於是查閱資料，做一個簡單的瞭解。
Eureka服務治理機制與Dubbo服務治理機制的比較
| Feature | Eureka | Zookeeper |
| 服務健康檢查 | 可配支持 | (弱)長連接，keepalive |
| CAP | AP | CP |
| watch支持 | （客戶端觀察到服務提供者變化）支持 long polling/大部分增量 | 支持 |
| 自我保護 | 支持 | - |
| 客戶端緩存 | 支持 | - |
| 自身集羣的監控 | metrics | - |
| Eureka支持健康檢查，自我保護等 |
Zookeeper爲CP設計，Eureka爲AP設計。作爲服務發現產品，可用性優先級較高，一致性的特點並不重要，寧可返回錯誤的數據，也比不反回結果要好得多。
服務列表變更Zookeeper服務端會有通知，Eureka則通過長輪詢來實現，Eureka未來會實現watch機制
CAP理論提出就是針對分佈式數據庫環境的，所以，P這個屬性是必須具備的。
P就是在分佈式環境中，由於網絡的問題可能導致某個節點和其它節點失去聯繫，這時候就形成了P(partition)，也就是由於網絡問題，將系統的成員隔離成了2個區域，互相無法知道對方的狀態，這在分佈式環境下是非常常見的。
因爲P是必須的，那麼我們需要選擇的就是A和C。
大家知道，在分佈式環境下，爲了保證系統可用性，通常都採取了複製的方式，避免一個節點損壞，導致系統不可用。那麼就出現了每個節點上的數據出現了很多個副本的情況，而數據從一個節點複製到另外的節點時需要時間和要求網絡暢通的，所以，當P發生時，也就是無法向某個節點複製數據時，這時候你有兩個選擇：
選擇可用性 A(Availability)，此時，那個失去聯繫的節點依然可以向系統提供服務，不過它的數據就不能保證是同步的了（失去了C屬性）。
選擇一致性C(Consistency)，爲了保證數據庫的一致性，我們必須等待失去聯繫的節點恢復過來，在這個過程中，那個節點是不允許對外提供服務的，這時候系統處於不可用狀態(失去了A屬性)。
最常見的例子是讀寫分離，某個節點負責寫入數據，然後將數據同步到其它節點，其它節點提供讀取的服務，當兩個節點出現通信問題時，你就面臨着選擇A（繼續提供服務，但是數據不保證準確），C（用戶處於等待狀態，一直等到數據同步完成）。
