ZooKeeper在HBase集群中的作用
ZooKeeper作为分布式协调组件，在大数据领域的其他分布式组件中往往扮演着重要的辅助角色，因此我们就算不单独去研究ZooKeeper，也短不了要接触它。本文就以最典型的HBase为例，简要介绍ZooKeeper为HBase提供了哪些功能。
下图示出一个完整HBase集群的架构，其中包含ZK节点。
HMaster、RegionServer容错当HBase集群启动成功后，会在ZK注册如下znode：/hbase/master，其中包含当前活动（即赢得选举）的HMaster信息；
/hbase/backup-masters/[host-name]，每个子znode包含当前作为热备的HMaster信息；
/hbase/rs/[host-name]，每个子znode包含各RegionServer的信息。
Log Split管理当RegionServer宕机时，除了重新路由Region之外，还得从宕机的RegionServer的WAL（即HLog）中恢复尚未持久化到HFile的数据。为了保证尽快完成failover过程，HBase会将HLog按Region切分成多个分片，并分配给对应的存活RegionServer再完成重放（replay）过程。如下图所示。
显然，Log Split的信息需要有一个中心组件来统一协调。HMaster会在ZK上注册/hbase/splitlog临时节点，其中存放有存活RegionServer与其应该处理的Region HLog的映射关系。各个RegionServer从该节点得到分配的Region，重放HLog，并将结果写回该节点，以通知HMaster进行后续操作。.META.表位置维护HBase中有一个特殊的表.META.（在0.98版本之前还有一个-ROOT-表，现已废弃，不再介绍），其中以类似B树的结构记录了集群内所有Region的位置信息，且该表不会split。而ZK通过永久（persistent）节点/hbase/meta-region-server来记录.META.表保存在哪个RegionServer上。
当客户端初次与HBase集群建立连接时，它首先查询上述ZK节点，再从持有.META.表的RegionServer获取到RowKey对应的Region位置信息并缓存起来，最后获取到对应的行做读写操作。如下图所示。
如果Region被移动，或客户端缓存失效，甚至.META.表所在的服务器故障，客户端总能通过ZK维护的路径获得正确的Region位置，不会造成不一致。Replication管理HBase的Replication是比较高级的功能，用于主集群和从集群之间的数据同步，从而支持容灾和备份。开启Replication之后，主集群会将数据实时地推送给各个从集群（可以是异步、同步或串行的），且保证数据的最终一致性。整个Replication的状态信息都储存在ZK的/hbase/replication这个znode下，主要有以下三个：
/hbase/replication/state：布尔值，表示Replication是否被启用；
/hbase/replication/peers：当前进行Replication的从集群对及其状态。每个peer会分配一个唯一ID；
/hbase/replication/rs：包含主集群上所有有效的RegionServer、 HLog文件的索引，以及HLog读取的偏移量。
多个HBase集群是可以共用一个ZK集群的。只需要修改HBase的zookeeper.znode.parent参数，对不同集群指定不同的ZK根路径即可，例如/hbase-cluster1、/hbase-cluster2，etc。
评论