Impala负载均衡方案——zookeeper

由来

之前根据Impala官方的文档尝试使用haproxy实现impalad节点的负载均衡，但是这种方案存在一些弊端，例如haproxy本身也是单点的，虽然可以通过keeplived实现haproxy的高可用，但是这样的配置难免有点太重了，实现impala负载均衡的同时还需要多部署两个组件，增大了系统运维的复杂度。在大数据生态圈中zookeeper是一个必不可少的自身具有高可用保证的组件，本文探讨如何使用zookeeper实现impalad的负载均衡。

HS2方案

众所周知，hiveserver2中可以集成zookeeper实现高可用，毕竟hiveserver2也可以视为无状态的服务，如果配置了zookeeper则在进程启动的时候向zk注册，可以同时注册多个hiveserver2服务，在jdbc连接的时候hive-jdbc可以识别获取服务的配置，然后再向这个服务发起连接，hiveserver2注册时会指定一个zookeeper的注册的根目录，每一个节点在注册的时候在该节点下写入一个节点，节点名为：

serverUri=db-87.photo.163.org:21050;version=1.2.1;sequence=0000000013

serverUri由hive.server2.thrift.bind.host和hive.server2.thrift.port配置决定的，version等于当前hiveserver2的版本号，sequence保持一个全局递增的序列号。

每一个节点的内容如下：

db-87.photo.163.org:21050
cZxid = 0x2500018ab0
ctime = Wed Dec 28 11:22:33 CST 2016
mZxid = 0x2500018ab0
mtime = Wed Dec 28 11:22:33 CST 2016
pZxid = 0x2500018ab0
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x358997ea0460d74
dataLength = 25
numChildren = 0

节点里面保存了注册时的一些信息，最主要的是第一行服务的IP和端口，这样在jdbc创建连接的时候客户端会随机选择一个服务节点并且用其信息替换掉jdbc url中原始的主机和端口信息，然后再尝试使用替换之后的url创建连接，如果创建失败则将其加入到error列表中，继续随机获取下一个节点，直到创建连接成功或者全部服务节点都不可用。

ZK方案

既然hiveserver2原生的带有这种特性，而impala又可以兼容hive-jdbc客户端，那么理所当然impala也可以使用这种方案实现负载均衡，现在的问题是impalad在启动的时候并不会向zookeeper注