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實現了服務器的自動切換，業務的不中斷；