keepalived与zookeeper都可以用来实现高可用，高可用一般跟负载均衡会一起考虑，所以通常也会考虑到相应的负载均衡能力，

以下是Keepalived与Zookeeper的对比：


一、概括对比：

1、Keepalived：

优点：简单，基本不需要业务层面做任何事情，就可以实现高可用，主备容灾。而且容灾的宕机时间也比较短。

缺点：也是简单，因为VRRP、主备切换都没有什么复杂的逻辑，所以无法应对某些特殊场景，比如主备通信链路出问题，会导致脑裂。同时，keepalived也不容易做负载均衡。


2、zookeeper：

优点：可以支持高可用，负载均衡。本身是个分布式的服务。

缺点：跟业务结合的比较紧密。需要在业务代码中写好ZK使用的逻辑，比如注册名字。拉取名字对应的服务地址等。


所以，区别很明显。从简单性来说：Keepalived最简单，zookeeper稍微复杂一些。

从负载均衡能力来看，zookeeper较强，Keepalived弱很多。

从与业务的紧密程度来看：zookeeper最紧密，而Keepalived基本跟业务层面没有关系。

keepalive只可以选出一台机器作为主机，所以keepalive只能实现M:1的备份
zookeeper可以选出N台机器作为主机，它可以实现M:N的备份


二、具体明细对比：
1.从主被动的角度考虑

    我们知道，nginx server通常和keepalived进行结合，那么keepalived是怎么知道nginx是否存活呢?是nginx主动向keepalived汇报信息？不是的。keepalived是主动向nginx发送请求，如果有响应，那么则nginx可用。

    对于zookeeper而言，HDFS，HBase，Yarn基于zookeeper做高可用，这里的zookeeper就是被动的，也就是说HDFS，HBase，Yarn主动向zookeeper中写数据。

2.从负载的角度来考虑

    keepalived可以帮助我们做到主从，主从的划分是通过配置文件（主从的priority之差>50）指定的，如果主没有挂掉，那么大量的请求通过主然后负载到后端的nginx，而从如果想要起作用只有等到主挂掉。

    而利用zookeeper做HA，zookeeper中可以说是“人人平等”，客户端无论访问follower，还是observer，异或是leader，都能给我们返回相应的结果，可以很好的实现了负载均衡，这也可以说是zookeeper的一个优点。


3.从存储数据的角度

    keepalived不可以存储数据，假设keepalived的主现在有50个连接，如果没有外部数据库存储这些连接的信息，主挂了的话，连接信息也就丢了，所以使用keepalived需要一个外部的数据库，但是如果主挂了的同时数据库也挂了，那么就over了，信息就会丢失，或者从起来后，连不上数据库，那么之前的连接信息也会丢失。

    zookeeper可以存储数据，zookeeper中可以创建一个zNode，里面存放数据，zookeeper可以做到一个分布式数据的一致性，zookeeper中每个节点的视图是一致的，数据本身可以做到最终一致性，也就是说其中一个server挂了，其他的server还有存的数据，那么这样的话就不需要额外的数据库，zookeeper本身就可以存储一定量的信息。这也可以说是zookeeper的另一个优点。


4.从业务的角度

    keepalived可以说比较简单，只需要简单的配置一下就可以了，使用keepalived的场景：如果我们只需要简单的知道当前的业务中哪个是主，哪个是从，那么可以选用keepalived。

    如果除了高可用以外，比如kafka，storm等还要想zookeeper中写一些数据，这时候就需要zookeeper。