一、常见的高可用解决方案

1、zookeeper

2、keepalived

3、DNS

二、keepalived和zookeeper对比

1、Keepalived

优点：简单，在实际接入Keepalived服务的时候，基本上不需要我们在业务层面做任何操作，就可以实现高可用，主备容灾。而且容灾的宕机时间也比较短。

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

2、zookeeper

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

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

3、DNS优点
优点：不复杂，同时与业务结合的不是很紧密，通过简单的逻辑就可以实现负载均衡。
缺点：DNS容灾是更新DNS服务器需要时间，宕机时间比较长。

所以，区别很明显。从简单性来说：Keepalived最简单，DNS次之，ZK最复杂。

从负载均衡能力来看，zookeeper最强，DNS次之，Keepalived最弱。

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

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

zookeeper可以选出N台机器作为主机，它可以实现M:N的备份

所以使用场景，个人看法，对于框架级别的业务可能会选择ZK，仅仅需要做容灾的用Keepalived。DNS的方法介乎两者中间。

二、具体明细对比

1、以主动和被动的角度考虑

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需要一个外部的数据库，但是如果主挂了的同时数据库也挂了，那么信息就会丢失，或者从起来后，连不上数据库，那么之前的连接信息也会丢失。

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

4、从业务的角度
keepalived相对来说比较简单，我们只需要关注配置文件，进行简单的配置就可以使用keepalived服务。使用keepalived的业务场景：如果我们只需要简单的知道当前的业务中哪个是主，哪个是从，那么可以选用keepalived。

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