在項目中使用了Nacos作為配置中心和服務注冊中心，不禁會想起Zookeeper也是可以做同樣的事情，那么兩者有什么異同處呢？終于找了一個時間整理出下面這篇文章。

主要平時用的較多是配置中心和服務注冊中心，所以也是結合這兩點功能做出對應的對比，主要比對集群模式。

以下僅僅整理了個人理解后的觀點，如有疑問歡迎咨詢討論。

1.Zookeeper

其實明白一點Zookeeper的功能主要是它的樹形節(jié)點來實現(xiàn)的。當有數(shù)據(jù)變化的時候或者節(jié)點過期的時候，會通過事件觸發(fā)通知對應的客戶端數(shù)據(jù)變化了，然后客戶端再請求zk獲取最新數(shù)據(jù)，采用push-pull來做數(shù)據(jù)更新。

ZK最重要的就是它的ZAB（消息廣播和崩潰恢復）協(xié)議了。
消息廣播： 集群中zk在數(shù)據(jù)更新的時候，通過leader節(jié)點將將消息廣播給其他follower節(jié)點，采用簡單的兩階段提交模式，先request->ack->commit，當超過一半的follower節(jié)點響應可以提交就更新代碼。

崩潰恢復： 當leader掛了，或者超半數(shù)follower投票得出leader不可用，那么會重新選舉，這段期間zk服務是不可用的。通過最新的 xid來選舉出新的leader，選舉出來后需要將新的leader中的數(shù)據(jù)更新給超過半數(shù)的follower節(jié)點才能對外提供服務。

2.Nacos

Nacos的配置中心和注冊中心實現(xiàn)的是兩套代碼，和Zk不同，

1.配置中心

Nacos和Zookeeper都可以作為配置中心，做一些可以實時變化的配置數(shù)據(jù)存儲，然后實時更新線上數(shù)據(jù)。

1.1 存儲和數(shù)據(jù)更新

Nacos：依賴Mysql數(shù)據(jù)庫做數(shù)據(jù)存儲，當有數(shù)據(jù)更新的時候，直接更新數(shù)據(jù)庫的數(shù)據(jù)，然后將數(shù)據(jù)更新的信息異步廣播給Nacos集群中所有服務節(jié)點數(shù)據(jù)變更，在由Nacos服務節(jié)點更新本地緩存，然后將通知客戶端節(jié)點數(shù)據(jù)變化。

Zookeeper:利用zk的樹型結構做數(shù)據(jù)存儲，當有數(shù)據(jù)更新的時候使用過半機制保證各個節(jié)點的數(shù)據(jù)一致性；然后通過zk的事件機制通知客戶端。

這里可以明顯發(fā)現(xiàn)差異：

• 服務器存儲位置不同，分別采用mysql和zk本身存儲
• 消息發(fā)送，一個有采用過半機制保持一致性，另外一個異步廣播，通過后臺線程重試保證。

2.注冊中心

Nacos：nacos支持兩種方式的注冊中心，持久化和非持久化存儲服務信息。

• 非持久直接存儲在nacos服務節(jié)點的內存中，并且服務節(jié)點間采用去中心化的思想，服務節(jié)點采用hash分片存儲注冊信息
• 持久化使用Raft協(xié)議選舉master節(jié)點，同樣采用過半機制將數(shù)據(jù)存儲在leader節(jié)點上

Zookeeper:利用zk的樹型結構做數(shù)據(jù)存儲，服務注冊和消費信息直接存儲在zk樹形節(jié)點上，集群下同樣采用過半機制保證服務節(jié)點間一致性

這里的差異：

• nacos支持持久化和非持久化存儲即有點 AP和CP 分布式一致性的概念，nacos的CP-持久化更像貼合zk的模式（過半機制），默認非持久化采用內存存儲速度更快，而且分片存儲，不利點就是某個服務節(jié)點掛掉，可能出現(xiàn)部分時間調用失敗。因為服務調用本身就是實時的，持久化存儲起來應該意義不大，及時變化才是真理。

所謂仁者見仁，智者見智。每一款產品都有各自的特點，具體看怎么用就看自身的業(yè)務的場景了。