| 服務註冊發現原理 | 一致性保障-CAP原理 | 服務註冊發現的時效性 | 容量 | |
|---|---|---|---|---|
| zookeeper | 集羣中分爲1個leader其他的機器爲follower，只有leader能夠進行寫操作，即服務註冊，然後把數據同步給follower，leader/follower都可以進行讀 | 保證CP，即一致性，當zk集羣中的leader掛掉，會重新進行leader的選舉，在此期間整個集羣處於不可用狀態，直到選舉出leader | 時效性更好，註冊或者掛了，一般秒級就能感知到 | zk不適合部署大規模服務實例，因爲服務上下線的時候，需要瞬間推送數據通知到所有的其他服務實例（consumer），所以一旦服務規模太大，到了幾千個機器的時候，會導致網絡帶寬短時間被大量佔用 |
| erueka | peer-to-peer,集羣中每臺機器的地位是相等的，各個服務可以向任何一個Eureka實例進行服務註冊和服務發現，集羣裏任何一個Eureka實例接收到寫請求之後，會自動同步給其他所有的Eureka實例 | 保證AP，一臺Eureka剛接受到服務註冊信息沒來得及同步到其他實例就掛了，其他實例依然可以提供服務發現功能，只不過數據不是最新的，只能保證最終一致性 | 默認配置下，服務發現和感知需要十幾秒甚至分鐘級別 | eureka也很難支撐大規模的服務實例，因爲每個eureka實例都要接受所有的請求 |
爲什麼zk時效性好
zk的客戶端可以在znode上創建watch對象，用於監聽znode的相關事件 新增子node、修改、刪除等，當發生事件時會及時獲得通知。
而eureka採用多級緩存，定時輪詢等存儲更新服務列表，所以時效性相對較差