CAP定理是分佈式系統設計中最基礎、最關鍵的理論，CAP定理又稱CAP原則，指的是在一個分佈式系統中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），最多隻能同時三個特性中的兩個，三者不可兼得
CAP的定義
Consistency (一致性)：
“all nodes see the same data at the same time”，即更新操作成功並返回客戶端後，所有節點在同一時間的數據完全一致，這就是分佈式的一致性。一致性的問題在併發系統中不可避免，對於客戶端來說，一致性指的是併發訪問時更新過的數據如何獲取的問題。從服務端來看，則是更新如何複製分佈到整個系統，以保證數據最終一致。即每次讀取要麼獲得最近寫入的數據，要麼獲得一個錯誤。
Availability (可用性):
可用性指“Reads and writes always succeed”，即服務一直可用，而且是正常響應時間。好的可用性主要是指系統能夠很好的爲用戶服務，不出現用戶操作失敗或者訪問超時等用戶體驗不好的情況。也就是每次請求都能獲得一個響應，這個響應是非錯誤的，但是不確保返回的是最新寫入的數據。
Partition Tolerance (分區容錯性):
即分佈式系統在遇到某節點或網絡分區故障的時候，仍然能夠對外提供滿足一致性或可用性的服務。
分區容錯性要求能夠使應用雖然是一個分佈式系統，而看上去卻好像是在一個可以運轉正常的整體。比如現在的分佈式系統中有某一個或者幾個機器宕掉了，其他剩下的機器還能夠正常運轉滿足系統需求，對於用戶而言並沒有什麼體驗上的影響。
取捨策略
CAP三個特性只能滿足其中兩個，那麼取捨的策略就共有三種：
CA without P：如果不要求P（不允許分區），則C（強一致性）和A（可用性）是可以保證的。但放棄P的同時也就意味着放棄了系統的擴展性，也就是分佈式節點受限，沒辦法部署子節點，這是違背分佈式系統設計的初衷的。比如兩階段提交（2PC）
CP without A：如果不要求A（可用），相當於每個請求都需要在服務器之間保持強一致，而P（分區）會導致同步時間無限延長(也就是等待數據同步完才能正常訪問服務)，一旦發生網絡故障或者消息丟失等情況，就要犧牲用戶的體驗，等待所有數據全部一致了之後再讓用戶訪問系統。注意，CP關注的是系統中大多數人的一致性協議，比如Paxos 算法 (Quorum 類的算法)。設計成CP的系統其實不少，最典型的就是分佈式數據庫，如Redis、HBase等。對於這些分佈式數據庫來說，數據的一致性是最基本的要求，因爲如果連這個標準都達不到，那麼直接採用關係型數據庫就好，沒必要再浪費資源來部署分佈式數據庫。eg. Zookeeper
AP without C：要高可用並允許分區，則需放棄一致性。一旦分區發生，節點之間可能會失去聯繫，爲了高可用，每個節點只能用本地數據提供服務，而這樣會導致全局數據的不一致性。典型的應用就如某米的搶購手機場景，可能前幾秒你瀏覽商品的時候頁面提示是有庫存的，當你選擇完商品準備下單的時候，系統提示你下單失敗，商品已售完。這其實就是先在 A（可用性）方面保證系統可以正常的服務，然後在數據的一致性方面做了些犧牲，雖然多少會影響一些用戶體驗，但也不至於造成用戶購物流程的嚴重阻塞。eg. Eureka
作爲服務發現產品，可用性優先級較高，一致性的特點則不重要，哪怕返回錯誤的數據，也比不返回結果要好一些。
服務列表變更Zookeeper服務端會有通知，Eureka則通過長輪詢來實現，將來會實現watch機制。
我司使用了Zookeeper作爲服務註冊發現中間件，但是如上文所述，Zookeeper是CP系統，無法保證分佈式下的可用性，需要使用AP系統。因此，公司大佬們實現AP系統服務註冊發現，保證了數據的最終一致性。根據 Netflix Eureka 研發並優化的golang版本服務註冊發現系統Discovery，與caster平臺進行結合，基於k8s pod(k8s項目中的原子調度單位)實現滾動發佈、藍綠髮布等，客戶端使用HTTP協議與註冊中心交互。 網絡閃斷時服務可開啓自我保護，保證健康的服務可用。由於公司各部門開發語言不一致，有golang、java、python、php、C++等，再實現各個語言的sdk，基於http協議保證交互簡易。