HBase第五天——HBase读写过程
HBase第五天——HBase 读写过程
自己的话：我愿平东海，身沉心不改；
大海无平期，我心无绝时。
HBase的读写过程及Master、Region的管理机制
一、读请求过程
1、Client 先访问 zookeeper，从 meta 表读取 region 的位置，然后读取 meta 表中的数据。meta中又存储了用户表的 region 信息；
2、根据 namespace、表名和 rowkey 在 meta 表中找到对应的 region 信息；
3、找到这个 region 对应的 regionserver；
4、查找对应的 region；
5、先从 MemStore 找数据，如果没有，再到 BlockCache 里面读；
6、BlockCache 还没有，再到 StoreFile 上读(为了读取的效率)；
7、如果是从 StoreFile 里面读取的数据，不是直接返回给客户端，而是先写入BlockCache，再返回给客户端。
二、写请求过程：
1、Client 向 HregionServer 发送写请求；
2、HregionServer 将数据写到HLog（write ahead log）。为了数据的持久化和恢复；
3、HregionServer 将数据写到内存（MemStore）；
4、反馈 Client 写成功。
注意：
（1）如果Memstore达到阈值，会把Memstore中的数据flush到Storefile中。
（2）当Storefile越来越多，会触发Compact合并操作，把过多的Storefile合并成一个大的Storefile。
（3）当Storefile越来越大，Region也会越来越大，达到阈值后，会触发Split操作，将Region一分为二。
三、Region管理
1. region分配
任何时刻，一个region只能分配给一个region server。master记录了当前有哪些可用的region server。以及当前哪些region分配给了哪些region server，哪些region还没有分配。当需要分配的新的region，并且有一个region server上有可用空间时，master就给这个region server发送一个装载请求，把region分配给这个region server。region server得到请求后，就开始对此region提供服务。
2. region server上线
master使用zookeeper来跟踪region server状态。当某个region server启动时，会首先在zookeeper上的server目录下建立代表自己的znode。由于master订阅了server目录上的变更消息，当server目录下的文件出现新增或删除操作时，master可以得到来自zookeeper的实时通知。因此一旦region server上线，master能马上得到消息。
3. region server下线
当region server下线时，它和zookeeper的会话断开，zookeeper而自动释放代表这台server的文件上的独占锁。master就可以确定：
(1)region server和zookeeper之间的网络断开了。
(2)region server挂了。
无论哪种情况，region server都无法继续为它的region提供服务了，此时master会删除server目录下代表这台region server的znode数据，并将这台region server的region分配给其它还活着的同志。
四、Master管理
1. master上线
master启动进行以下步骤:
（1）从zookeeper上获取唯一一个代表active master的锁，用来阻止其它master成为master。
（2）扫描zookeeper上的server父节点，获得当前可用的region server列表。
（3）和每个region server通信，获得当前已分配的region和region server的对应关系。
（4）扫描.META.region的集合，计算得到当前还未分配的region，将他们放入待分配region列表。
2. master下线
由于master只维护表和region的元数据，而不参与表数据IO的过程，master下线仅导致所有元数据的修改被冻结(无法创建删除表，无法修改表的schema，无法进行region的负载均衡，无法处理region 上下线，无法进行region的合并，唯一例外的是region的split可以正常进行，因为只有region server参与)，表的数据读写还可以正常进行。因此master下线短时间内对整个hbase集群没有影响。
从上线过程可以看到，master保存的信息全是可以冗余信息（都可以从系统其它地方收集到或者计算出来）
因此，一般hbase集群中总是有一个master在提供服务，还有一个以上的‘master’在等待时机抢占它的位置。