Master上线
1) 从Zookeeper上获取唯一一个代表Active Master的锁，用来阻止其他Master成为真正的Master
2) 扫描Zookeeper上的/hbase/rs节点，获取当前可用的Region server列表
3) 和每个RegionServer通信，获得当前已分配的Region和RegionServer的对应关系
4) 扫描.MATA.表数据，计算得到当前还未分配的Region，将他们放入待分配Region列表
Master下线
1) 由于Master只维护表和Region的元数据，不参与表数据IO的过程，Master下线导致所有元数据的修改被冻结（无法创建删除表、无法修改表的schema、无法进行Region的负载均衡、无法处理Region上下线、无法进行Region的合并，唯一例外的是Region的split可以正常进行，因为只有RegionServer参与），表的数据读写还可以正常进行。因此Master下线短时间内对整个hbase集群没有影响
2) Master下线，启用Zookeeper的选举机制，确定新的Master，新的Master执行上线流程
RegionServer上线
1) Master使用Zookeeper来跟踪RegionServer的状态
2) 当某个RegionServer启动时，会首先在Zookeeper上的/hbase/rs目录下建立代表自己的znode
3) 由于Master订阅了/hbase/rs目录上的变更消息，当/hbase/rs目录下的文件出现新增或删除操作时，Master可以得到来自Zookeeper的实时通知
4) 因此一旦RegionServer上线，Master能马上得到消息
RegionServer下线
精简版：
1) 当RegionServer下线时，它和Zookeeper的会话断开
2) Zookeeper从而自动释放代表这台RegionServer的文件上的独占锁
3) Zookeeper通知Master该RegionServer下线
4) Master将该RegionServer上的Region分配给其他还活着的RegionServer
完整版：
1) 当RegionServer下线时，它和Zookeeper的会话断开
2) Zookeeper从而自动释放代表这台RegionServer的文件上的独占锁
3) 而Master不断轮询Server目录下文件的锁状态，如果Master发现某个RegionServer丢失自己的的独占锁，或者Master连续几次和RegionServer通信都无法成功，Master就尝试去获取代表这个RegionServer的读写锁；一旦获取成功，就可以确定RegionServer和Zookeeper之间的网络断开或RegionServer挂了。无论哪种情况发生，RegionServer都无法继续为它的Region提供服务，此时Master会删除Server目录下代表这台RegionServer的文件，并将这台RegionServer的Region分配给其他还活着的节点
4) 如果网络短暂出现问题导致RegionServer丢失它的锁，RegionServer重新连接到Zookeeper之后，只要代表它的文件还在，它就会不断尝试这个文件上的锁，一旦获取到，就可以继续提供服务
Region管理
1) 任何时刻，一个Region只能分配给一个RegionServer
2) Master记录了当前有哪些可用的RegionServer，以及当前哪些Region分配给了哪些
Region server，哪些Region还没有分配
3) 当需要分配的新的Region，并且有一个RegionServer上有可用空间时，Master就给这个
RegionServer发送一个装载请求，把Region分配给这个RegionServer，RegionServer得到请求后，就开始对此Region提供服务
