keepalived和zookeeper對比

https://blog.csdn.net/vtopqx/article/details/79066703

keepalived與zookeeper都可以用來實作高可用，高可用一般跟負載均衡會一起考慮，是以通常也會考慮到相應的負載均衡能力，

以下是Keepalived與Zookeeper的對比：

1、概括對比：

1.1、Keepalived：

優點：簡單，基本不需要業務層面做任何事情，就可以實作高可用，主備容災。而且容災的當機時間也比較短。

缺點：也是簡單，因為VRRP、主備切換都沒有什麼複雜的邏輯，是以無法應對某些特殊場景，比如主備通信鍊路出問題，會導緻腦裂。同時，keepalived也不容易做負載均衡。

1.2、zookeeper：

優點：可以支援高可用，負載均衡。本身是個分布式的服務。

缺點：跟業務結合的比較緊密。需要在業務代碼中寫好ZK使用的邏輯，比如注冊名字。拉取名字對應的服務位址等。

是以，差別很明顯。從簡單性來說：Keepalived最簡單，zookeeper稍微複雜一些。

從負載均衡能力來看，zookeeper較強，Keepalived弱很多。

從與業務的緊密程度來看：zookeeper最緊密，而Keepalived基本跟業務層面沒有關系。

keepalive隻可以選出一台機器作為主機，是以keepalive隻能實作M:1的備份

zookeeper可以選出N台機器作為主機，它可以實作M:N的備份

2、具體明細對比：

2.1、從主被動的角度考慮

    我們知道，nginx server通常和keepalived進行結合，那麼keepalived是怎麼知道nginx是否存活呢?是nginx主動向keepalived彙報資訊？不是的。keepalived是主動向nginx發送請求，如果有響應，那麼則nginx可用。

    對于zookeeper而言，HDFS，HBase，Yarn基于zookeeper做高可用，這裡的zookeeper就是被動的，也就是說HDFS，HBase，Yarn主動向zookeeper中寫資料。

2.2、從負載的角度來考慮

    keepalived可以幫助我們做到主從，主從的劃分是通過配置檔案（主從的priority之差>50）指定的，如果主沒有挂掉，那麼大量的請求通過主然後負載到後端的nginx，而從如果想要起作用隻有等到主挂掉。

    而利用zookeeper做HA，zookeeper中可以說是“人人平等”，用戶端無論通路follower，還是observer，異或是leader，都能給我們傳回相應的結果，可以很好的實作了負載均衡，這也可以說是zookeeper的一個優點。

2.3、從存儲資料的角度

    keepalived不可以存儲資料，假設keepalived的主現在有50個連接配接，如果沒有外部資料庫存儲這些連接配接的資訊，主挂了的話，連接配接資訊也就丢了，是以使用keepalived需要一個外部的資料庫，但是如果主挂了的同時資料庫也挂了，那麼就over了，資訊就會丢失，或者從起來後，連不上資料庫，那麼之前的連接配接資訊也會丢失。

    zookeeper可以存儲資料，zookeeper中可以建立一個zNode，裡面存放資料，zookeeper可以做到一個分布式資料的一緻性，zookeeper中每個節點的視圖是一緻的，資料本身可以做到最終一緻性，也就是說其中一個server挂了，其他的server還有存的資料，那麼這樣的話就不需要額外的資料庫，zookeeper本身就可以存儲一定量的資訊。這也可以說是zookeeper的另一個優點。

2.4、從業務的角度

    keepalived可以說比較簡單，隻需要簡單的配置一下就可以了，使用keepalived的場景：如果我們隻需要簡單的知道目前的業務中哪個是主，哪個是從，那麼可以選用keepalived。

    如果除了高可用以外，比如kafka，storm等還要想zookeeper中寫一些資料，這時候就需要zookeeper。

3、總結

一句話：zookeeper主要就是為了保持資料的一緻性來的；

keepalived實作了伺服器的自動切換，業務的不中斷；