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实现了服务器的自动切换,业务的不中断;

原文地址:https://www.cnblogs.com/guanghe/p/10510588.html