原理前面介绍了HBase的一般架构，我们知道了HBase有ZK、Master和RS等组成，本节我们来介绍下HBase的基本原理，从数据访问、RS路由到RS内部缓存、数据存储和刷写再到region的合并和拆分等等功能。
RegionServer定位访问HBase通过HBase客户端(或API)进行，整个HBase提供给外部的地址，其实是ZK的入口，前面也介绍了，ZK中有保存 -ROOT-所在的RS地址，从-ROOT-表可以获取.META.表信息，根据.META.表可以获取region在RS上的分布，整个region寻 址过程大致如下：
- 首先，Client通过访问ZK来请求目标数据的地址。
- ZK中保存了-ROOT-表的地址，所以ZK通过访问-ROOT-表来请求数据地址。
- 同样，-ROOT-表中保存的是.META.的信息，通过访问.META.表来获取具体的RS。
- .META.表查询到具体RS信息后返回具体RS地址给Client。
- Client端获取到目标地址后，然后直接向该地址发送数据请求。
上述过程其实是一个三层索引结构，从ZK获取-ROOT-信息，再从-ROOT-获取.META.表信息，最后从.META.表中查到RS地址后缓存。这里有几个问题：
- 既然ZK中能保存-ROOT-信息，那么为什么不把.META.信息直接保存在ZK中，而需要通过-ROOT-表来定位？
- Client查找到目标地址后，下一次请求还需要走ZK –> -ROOT- –>.META.这个流程么？
先来回答第一个问题：为什么不直接把.META.表信息直接保存到ZK中？主要是为了保存的数据量考虑，ZK中不宜保存大量数据，而.META.表 主要是保存Region和RS的映射信息，region的数量没有具体约束，只要在内存允许的范围内，region数量可以有很多，如果保存在ZK 中，ZK的压力会很大。所以，通过一个-ROOT-表来转存到RS中是一个比较理想的方案，相比直接保存在ZK中，也就多了一层-ROOT-表的查询，对 性能来说影响不大。
第二个问题：每次访问都需要走ZK –> -ROOT- —> .META.的流程么？当然不需要，Client端有缓存，第一次查询到相应region所在RS后，这个信息将被缓存到Client端，以后每次访问都 直接从缓存中获取RS地址即可。当然这里有个意外：访问的region若果在RS上发生了改变，比如被balancer迁移到其他RS上了，这个时候，通 过缓存的地址访问会出现异常，在出现异常的情况下，Client需要重新走一遍上面的流程来获取新的RS地址。总体来说，region的变动只会在极少数 情况下发生，一般变动不会很大，所以在整个集群访问过程中，影响可以忽略。
Region数据写入HBase通过ZK –> -ROOT- –>.META.的访问获取RS地址后，直接向该RS上进行数据写入操作，整个过程如下图：
Client通过三层索引获得RS的地址后，即可向指定RS的对应region进行数据写入，HBase的数据写入采用WAL(write ahead log)的形式，先写log，后写数据。HBase是一个append类型的数据库，没有关系型数据库那么复杂的操作，所以记录HLog的操作都是简单的 put操作(delete/update操作都被转化为put进行)
HLogHLog写入HLog是HBase实现WAL方式产生的日志信息，其内部是一个简单的顺序日志，每个RS上的region都共享一个HLog，所有对于该RS上的 region数据写入都被记录到该HLog中。HLog的主要作用就是在RS出现意外崩溃的时候，可以尽量多的恢复数据，这里说是尽量多，因为在一般情况 下，客户端为了提高性能，会把HLog的auto flush关掉，这样HLog日志的落盘全靠操作系统保证，如果出现意外崩溃，短时间内没有被fsync的日志会被丢失。
HLog过期HLog的大量写入会造成HLog占用存储空间会越来越大，HBase通过HLog过期的方式进行HLog的清理，每个RS内部都有一个HLog监控线程在运行，其周期可以通过hbase.master.cleaner.interval进行配置。
HLog在数据从memstore flush到底层存储上后，说明该段HLog已经不再被需要，就会被移动到.oldlogs这个目录下，HLog监控线程监控该目录下的HLog，当该文 件夹下的HLog达到hbase.master.logcleaner.ttl设置的过期条件后，监控线程立即删除过期的HLog。 |
