HBase入门5(集群) -压力分载与失效转发

在上一篇关于HBase的文章中曾经讲述过HBase在分布式中的架构，这篇文章将会讲述HBase在分布式环境中是如何排除单点故障的(SPFO)，做一个小实验讲述HBase在分布式环境中的高可用性，亲眼看到一些现象，延伸一些思考的话题。

先来回顾一下HBase主要部件：
   1.HBaseMaster  
   2.HRegionServer 
   3.HBase Client
   4.HBase Thrift Server
   5.HBase REST Server

HBaseMaster
    HMaster 负责给HRegionServer分配区域,并且负责对集群环境中的HReginServer进行负载均衡，HMaster还负责监控集群环境中的HReginServer的运行状况，如果某一台HReginServer down机，HBaseMaster将会把不可用的HReginServer来提供服务的HLog和表进行重新分配转交给其他HReginServer来提供，HBaseMaster还负责对数据和表进行管理，处理表结构和表中数据的变更，因为在 META 系统表中存储了所有的相关表信息。并且HMaster实现了ZooKeeper的Watcher接口可以和zookeeper集群交互。

HRegionServer
    HReginServer负责处理用户的读和写的操作。HReginServer通过与HBaseMaster通信获取自己需要服务的数据表，并向HMaster反馈自己的运行状况。当一个写的请求到来的时候，它首先会写到一个叫做HLog的write-ahead log中。HLog被缓存在内存中，称为Memcache，每一个HStore只能有一个Memcache。当Memcache到达配置的大小以后，将会创建一个MapFile，将其写到磁盘中去。这将减少HReginServer的内存压力。当一起读取的请求到来的时候，HReginServer会先在Memcache中寻找该数据，当找不到的时候，才会去在MapFiles 中寻找。

HBase Client
    HBase Client负责寻找提供需求数据的HReginServer。在这个过程中，HBase Client将首先与HMaster通信，找到ROOT区域。这个操作是Client和Master之间仅有的通信操作。一旦ROOT区域被找到以后，Client就可以通过扫描ROOT区域找到相应的META区域去定位实际提供数据的HReginServer。当定位到提供数据的HReginServer以后，Client就可以通过这个HReginServer找到需要的数据了。这些信息将会被Client缓存起来，当下次请求的时候，就不需要走上面的这个流程了。

HBase服务接口
    HBase Thrift Server和HBase REST Server是通过非Java程序对HBase进行访问的一种途径。

进入正题

先来看一个HBase集群的模拟环境，此环境中一共有4台机器，分别包含zookeeper、HBaseMaster、HReginServer、HDSF 4个服务，为了展示失效转发的效果HBaseMaster、HReginServer各有2台，只是在一台机器上即运行了HBaseMaster，也运行了HReginServer。
注意，HBase的集群环境中HBaseMaster只有失效转发没有压力分载的功能，而HReginServer即提供失效转发也提供压力分载。

服务器清单如下：
    1、zookeeper              192.168.20.214
    2、HBaseMaster        192.168.20.213/192.168.20.215
    3、HReginServer        192.168.20.213/192.168.20.215
    4、HDSF                       192.168.20.212

整个模拟环境的架构如图所示：

注意，这里只是做了一个模拟环境，因为这个环境的重点是HBase，所以zookeeper和HDFS服务都是单台。

虽然说在整个HBase的集群环境中只能有一个HMaster，可是在集群环境中HMaster可以启动多个，但真正使用到的HMaster Server只有一个，他不down掉的时候，其他启动的HMasterServer并不会工作，直到与ZooKeeper服务器判断与当前运行的HMaster通讯超时，认为这个正在运行的HMaster服务器down掉了，Zookeeper才会去连接下一台HMaster Server。

简单来说,如果运行中HMaster服务器down掉了，那么zookeeper会从列表中选择下一个HMaster 服务器进行访问，让他接管down掉的HMaster任务，换而言之，用Java客户端对HBase进行操作是通过ZooKeeper的，也就是说如果zookeeper集群中的节点全挂了那么HBase的集群也挂了。本身HBase并不存储中的任何数据 真正的数据是保存在HDFS上，所以HBase的数据是一致的，但是HDFS文件系统挂了，HBase的集群也挂。

在一台HMaster失败后，客户端对HBase集群环境访问时，客户端先会通过zookeeper识别到HMaster运行异常，直到确认多次后，才连接到下一个HMaster，此时，备份的HMaster服务才生效，在IDE环境中的效果，如图所示：

上图中能看见抛出的一些异常和name:javahttp://www.javabloger.com和name:javahttp://www.javabloger.com1的结果集，因为我在serv215机器上用killall java命令把 HMaster和HReginServer都关掉，并且立刻用Java客户端对HBase的集群环境进行访问有异常抛出，但是retry到一定次数后查询出结果，前面已经说了访问HBase是通过zookeeper再和真正的数据打交道，也就是说zookeeper接管了一个standby 的 HMaster，让原先Standby的HMaster接替了失效的HMaster任务，而被接管的HBaseMaster再对HReginServer的任务进行分配，当 HReginServer失败后zookeeper会通知 HMaster对HReginServer的任务进行分配。这样充分的说明了HBase做到了实效转发的功能。
如图所示：
 

口水：
1、HBase的失效转发的效率比较慢了，不指望能在1-2秒切换和恢复完毕，也许是我暂时没有发现有什么参数可以提高失效转发和恢复过程的速度，将来会继续关注这个问题。
2、在官方网站上看见HBase0.89.20100924的版本有篇讲述关于数据同步的文章，我尝试了一下在一台机器上可以运行所谓的HBase虚拟集群环境，但是切换到多台机器的分布式环境中，单点失效转发的速度很慢比HBase0.20.6还要慢，我又检查了是否存在网络的问题，目前尚未找到正确的答案，对与HBase0.89.20100924 新版中的数据同步的原理，如图所示：(更多信息)