关于HABSE

什么是Hbase

hbase是bigtable的开源java版本。是建立在hdfs之上，提供高可靠性、高性能、列存储、可伸缩、实时读写nosql的数据库系统。
它介于nosql(非关系型数据库)和RDBMS(关系型数据库)之间，仅能通过主键(row key)和主键的range来检索数据，仅支持单行事务(可通过hive支持来实现多表join等复杂操作)。

Hbase查询数据功能很简单，不支持join等复杂操作，不支持复杂的事务（行级的事务）
Hbase中支持的数据类型：byte[]

---

Hbase存储数据的冷热分离

冷数据：是对于离线类不经常访问的数据，比如企业备份数据、业务与操作日志数据、话单与统计数据。

热数据：是需要被计算节点频繁访问的在线类数据。

方案一：主备集群

搞两个集群，一个集群是SSD的配置，负责在线查询，另一个集群是机械盘HDD的配置。 这两张表之间需要手动进行同步，并且客户端需要感知两个集群的配置。
优点：方案简单，现成内核版本都能搞
缺点：维护开销大，冷集群CPU存在浪费
（只有1.x版本不改内核才使用这种方案）

方案二：HDFS Archival Storage + HBase CF-level Storage Policy（就是指定hdfs的表存不同介质）

在2.0的HBase的版本中新加入了一个特性，可以指定表的HDFS存在哪种介质上。这利用了HDFS的分级存储功能，HDFS的分级存储功能，可以将DataNode配置到不同介质的盘。比如上图中有三块是机械盘一块SSD，在表上可以设置这样的策略，指定表的HDFS是写在冷介质还是热介质上，最后调到HDFS接口的时候，会根据设置的文件的属性放置数据。

需要在2.x之后的版本才能使用。结合HDFS分层存储能力 + 在Table层面指定数据存储策略，实现同集群下，不同表数据的冷热分离。

优点：同一集群冷热分离，维护开销少，更灵活的配置不同业务表的策略
缺点：磁盘配比是个很大的问题，不同业务冷热配比是不一样的，比较难整合在一起，一旦业务变动，集群硬件配置是没法跟着变的

方案三：云服务器OSS云HBase云端方案

阿里云oss

---

Hbase在hdfs上的目录结构

参考、
这是hdfs上Hbase下的目录结构

/hbase/.hbase-snapshot

HBase 从0.95开始引入了Snapshot，可以对table进行Snapshot，也可以Restore到Snapshot。Snapshot可以在线做，也可以离线做。Snapshot的实现不涉及到table实际数据的拷贝，仅仅拷贝一些元数据，比如组成table的region info，表的descriptor，还有表对应的HFile的文件的引用。
snapshot源码解析

/hbase/.tmp

.tmp是临时目录，是一个空目录，用于hbase临时存放数据

/hbase/MasterProcWALs

目录下含有一个HMaster主节点状态日志文件，MasterProcWals状态日志过多导致的HBase Master重启失败问题，CDH上面可以通过日志清理插件定时清理

/hbase/WALs

预写日志目录，主要用于存储RegionServer的操作日志。顺带一提预写日志wal机制
预写日志（Write-ahead log，WAL）
最重要的作用是灾难恢复，一旦服务器崩溃，通过重放log，我们可以恢复崩溃之前的数据。如果写入
WAL失败，整个操作也将认为失败。

1 客户端对数据执行一个修改操作，如put(),delete(),incr()等。
2 每一个修改被封装到一个KeyValue对象实例，并通过RPC调用发送出来。
3 上述调用成批地发送给含有匹配region的HRegionServer。
4 数据先被写入到WAL，然后被放放到实际拥有记录的存储文件的MemStore中。
5 当MemStore达到一定的大小或经历一个特定时间之后，数据会异步地连续写入到文件系统中。

由于实际的日志存储在HDFS上，所以即使在服务器完全崩溃的情况下，WAL也能保证数据不会丢失。其他服务器可以打开日志文件然后回放这些修改。

/hbase/archive

HBase的HFile会存在合并的机制，当HFile合并了以后，就不再是原来的HFile了，那么快照是如何保证在HFile合并后防止snapshot失效的问题？

解答：HBase的实现是将原始表的数据复制到archive目录下，再进行compact，这样spapshot就不会因为HBase的合并而失效了。在做完快照以后，你可以尝试对该表做major_compact操作，执行major_compact后，就能在archive目录下看到对应表的相关备份文件了。

/hbase/data（data存储Region中的StoreFile。）

data目录是最重要的目录，存储hbase数据，下面含有两个命名空间default和hbase，其中default是默认命名空间，如果创建的表未指定命名空间，将存放在该命名空间下，habse是系统命名空间，他们分别对应default和hbase目录，其中刚开始default目录为空，而hbase目录结构如下：

/hbase/hbase.id

HBase集群的唯一标识。

hbase.version

HBase集群的版本号。

oldWALs

当WALs目录下的日志文件超过一定时间后，会将其移动到oldWALs目录中，Master会定期进行清理。
开启snapshot后不会自定清理，需要手动清理

---

ROOT表：（0.96后的版本更名为NameSpace）

①记录的是RowKey粗粒度的信息。
②通过查询zookeeper定位到ROOT的位置。
③-ROOT-表最终是存储在HBase中的，zookeeper中仅仅记录了-ROOT-表的元数据信息而已
④在一个HBase分布式集群中，只有一张ROOT表，且-ROOT-表只包含一个Region
⑤根据**-ROOT-表中的每一条记录定位到.META.表的位置**，以及行键的取值的范围

---

META表：（新版本：hbase:meta）

①记录的是RowKey细粒度的信息（细化到根据每条记录，可以定位到记录到底应该存储在哪台
HRegionServer的HRegion中的表）
②.METa.表的元数据信息没有存储在zookeeper中，通过-ROOT-表中的记录信息定位到的
③.META.表可以包含多个HRegion

---

HMaster

HMaster 是 HBase 集群中的主服务器，负责监控集群中的所有 RegionServer，并且是所有元数据更改的接口。HMaster一般运行在集群的namenode上，HMaster 通过 ZooKeeper 来避免单点故障，在集群中可以启动多个 HMaster，但 ZooKeeper 的选举机制能够保证同时只有一个 HMaster 处于 Active 状态，其他的 HMaster 处于热备份状态。

1. 管理HRegionServer，实现其负载均衡。
2. 管理和分配HRegion，比如在HRegion split时分配新的HRegion；
3. 在HRegionServer退出时迁移其内的HRegion到其他HRegionServer上。实现DDL操作（Data Definition Language，namespace和table的增删改，column familiy的增删改等）。
4. 管理namespace和table的元数据（实际存储在HDFS上）。
5. 权限控制（ACL）。

HRegionServer

在 HDFS 中，DataNode 负责存储实际数据。RegionServer 主要负责响应用户的请求，向 HDFS 读写数据。一般在分布式集群中，RegionServer 运行在 DataNode 服务器上，实现数据的本地性。

每个 HRegionServer 包含多个 HRegion，它负责的功能如下：

1. 处理分批给它的 Region。
2. 处理客户端读写请求。
3. 刷新缓存到 HDFS 中。
4. 处理 Region 分片。
5. 执行压缩。

HRegion

每个 Region 由多个 HStore 组成，每个 HStore 对应表中一个列族的存储。

HBase 是按列进行存储的，将列族作为一个集中的存储单元，并且 HBase 将具备相同 I/O 特性的列存储到一个列族中，这样可以保证读写的高效性。

假设我们有100亿条数据，这么大的数据无法存储到一台机器上，这时hbase水平切分成不同的分片，分片就是region,一个regionServer包含若干region,由于是水平切分，一条完整的数据一定是只属于一个region,其实hbase底层存存储结构是key-value形式的,key就是row-key。

HBase使用RowKey将表水平切割成多个HRegion，从HMaster的角度，每个HRegion都纪录了它的StartKey和EndKey（第一个HRegion的StartKey为空，最后一个HRegion的EndKey为空），由于RowKey是排序的，因而Client可以通过HMaster快速的定位每个RowKey在哪个HRegion中。

HRegion由HMaster分配到相应的HRegionServer中，然后由HRegionServer负责HRegion的启动和管理，和Client的通信，负责数据的读(使用HDFS)。

HLog

HLog与HRegionServer一一对应
HLog持久化在HDFS之上
查看 HLog存储位置→
hadoop fs -ls /hbase/WALs
如果HLog已经失效(所有之前的写入
MemStore已经持久化在HDFS),HLog存
在于HDFS之上的文件会从/hbase/.logs转
移至/hbase/oldWALs, oldlogs会删除,
HLog的生命周期结束.

向HBase Put数据时通过HBaseClient–>
连接ZooKeeper—>-ROOT—>.META.–
->RegionServer–>Region:

列族column family

它是column的集合，在创建表的时候就指定，不能频繁修改。值得注意的是，列族的数量越少越好，因为过多的列族相互之间会影响，生产环境

中的列族一般是一个到两个。数据的持久化文件HFile中是按照Key-Value存储的，同一个列族的所有列存储在同一个底层存储文件里。每个列族在物理上有自己的Hfile集合，Hbase的数据在HDFS中的路径结构如下：

hdfs://h201:8020/hbase/data/${名字空间}/${表名}/${区域名称}/${列族名称}/${文件名}

列column

和列族的限制数量不同，列族可以包含很多个列，前面说的“几十亿行*百万列”就是这个意思。

列的值cell

存在单元格(cell)中。每一列的值允许有多个版本，由timestamp来区分不同版本。多个版本产生原因：向同一行下面的同一个列多次插入数据，

每插入一次就有一个对应版本的value。

1.hbase的特点是什么？

答：1)hbase是一个分布式的，基于列式存储的数据库，基于hadoop的hdfs存储，使用zookeeper进行管理。

2)hbase 适合存储半结构化或非结构化的数据，对于数据结构字段不够确定或者杂乱无章很难按照一个概念去抽取的数据。

3)hbase为null的数据不会被存储

4)基于的表包含rowKey，时间戳和列族，新写入数据时，时间戳更新，同时可以查询到以前的版本

5）hbase是主从结构，hmaster作为主节点，hregionServer作为从节点

2.hbase如何导入数据？
　　使用 MapReduce Job 方式，根据 Hbase API 编写 java 脚本，将文本文件用文件流的方式截取，然后存储到多个字符串数组中，在 put 方法下，通过对表中的列族进行 for 循环遍历列名，用 if 判断列名后进行 for 循环调用 put.add 的方法对列族下每一个列进行设值，每个列族下有几个了就赋值几次！没有表先对先创建表。

3.hbase 的存储结构？ 　　
　　答： Hbase 中的每张表都通过行键(rowkey)按照一定的范围被分割成多个子表（HRegion），默认一个 HRegion 超过 256M 就要被分割成两个，由 HRegionServer 管理，管理哪些 HRegion由 Hmaster 分配。 HRegion 存取一个子表时，会创建一个 HRegion 对象，然后对表的每个列族（Column Family）创建一个 store 实例，每个 store 都会有 0 个或多个 StoreFile 与之对应，每个 StoreFile 都会对应一个 HFile， HFile 就是实际的存储文件，因此，一个 HRegion 还拥有一个 MemStore 实例。

4.Hbase 和 hive 有什么区别hive 与 hbase 的底层存储是什么？hive是产生的原因是什么？habase是为了弥补hadoop的什么缺陷？
答案:共同点：1.hbase与hive都是架构在hadoop之上的。都是用hadoop作为底层存储

区别：2.Hive是建立在Hadoop之上为了减少MapReducejobs编写工作的批处理系统，HBase是为了支持弥补Hadoop对实时操作的缺陷的项目 。

3.想象你在操作RMDB数据库，如果是全表扫描，就用Hive+Hadoop,如果是索引访问，就用HBase+Hadoop 。

4.Hive query就是MapReduce jobs可以从5分钟到数小时不止，HBase是非常高效的，肯定比Hive高效的多。

5.Hive本身不存储和计算数据，它完全依赖于HDFS和MapReduce，Hive中的表纯逻辑。

6.hive借用hadoop的MapReduce来完成一些hive中的命令的执行

7.hbase是物理表，不是逻辑表，提供一个超大的内存hash表，搜索引擎通过它来存储索引，方便查询操作。

8.hbase是列存储。

9.hdfs作为底层存储，hdfs是存放文件的系统，而Hbase负责组织文件。

10.hive需要用到hdfs存储文件，需要用到MapReduce计算框架。

5.解释下 hbase 实时查询的原理
　　答：实时查询，可以认为是从内存中查询，一般响应时间在 1 秒内。 HBase 的机制是数据先写入到内存中，当数据量达到一定的量（如 128M），再写入磁盘中， 在内存中，是不进行数据的更新或合并操作的，只增加数据，这使得用户的写操作只要进入内存中就可以立即返回，保证了 HBase I/O 的高性能。

6.列簇怎么创建比较好？(<=2)
答： rowKey 最好要创建有规则的 rowKey，即最好是有序的。 HBase 中一张表最好只创建一到两个列族比较好，因为 HBase 不能很好的处理多个列族。

7.描述 Hbase 中 scan 和 get 的功能以及实现的异同.
1.按指定RowKey 获取唯一一条记录， get方法（org.apache.hadoop.hbase.client.Get）Get 的方法处理分两种 : 设置了 ClosestRowBefore 和没有设置的 rowlock .主要是用来保证行的事务性，即每个 get 是以一个 row 来标记的.一个 row 中可以有很多 family 和 column.

2.按指定的条件获取一批记录， scan 方法(org.apache.Hadoop.hbase.client.Scan)实现条件查询功能使用的就是 scan 方式.1)scan 可以通过 setCaching 与 setBatch 方法提高速度(以空间换时间)； 2)scan 可以通过 setStartRow 与 setEndRow 来限定范围([start， end]start 是闭区间， end 是开区间)。范围越小，性能越高。3)scan 可以通过 setFilter 方法添加过滤器，这也是分页、多条件查询的基础。

3.全表扫描，即直接扫描整张表中所有行记录

8.请详细描述 Hbase 中一个 Cell 的结构
HBase 中通过 row 和 columns 确定的为一个存贮单元称为 cell。Cell：由{row key, column(= + ), version}是唯一确定的单元 cell中的数据是没有类型的，全部是字节码形式存贮

9.请描述 Hbase 中 scan 对象的 setCache 和 setBatch 方法的使用.
cache：
在默认情况下，如果你需要从hbase中查询数据，在获取结果ResultScanner时，hbase会在你每次调用ResultScanner.next（）操作时对返回的每个Row执行一次RPC操作。即使你使用ResultScanner.next(int nbRows)时也只是在客户端循环调用RsultScanner.next()操作，你可以理解为hbase将执行查询请求以迭代器的模式设计，在执行next（）操作时才会真正的执行查询操作，而对每个Row都会执行一次RPC操作。

 因此显而易见的就会想如果我对多个Row返回查询结果才执行一次RPC调用，那么就会减少实际的通讯开销。这个就是hbase配置属性“hbase.client.scanner.caching”的由来，设置cache可以在hbase配置文件中显示静态的配置，也可以在程序动态的设置。

 cache值得设置并不是越大越好，需要做一个平衡。cache的值越大，则查询的性能就越高，但是与此同时，每一次调用next（）操作都需要花费更长的时间，因为获取的数据更多并且数据量大了传输到客户端需要的时间就越长，一旦你超过了maximum heap the client process 拥有的值，就会报outofmemoryException异常。当传输rows数据到客户端的时候，如果花费时间过长，则会抛出ScannerTimeOutException异常。

batch：
在cache的情况下，我们一般讨论的是相对比较小的row，那么如果一个Row特别大的时候应该怎么处理呢？要知道cache的值增加，那么在client process 占用的内存就会随着row的增大而增大。在hbase中同样为解决这种情况提供了类似的操作：Batch。可以这么理解，cache是面向行的优化处理，batch是面向列的优化处理。它用来控制每次调用next（）操作时会返回多少列，比如你设置setBatch（5），那么每一个Result实例就会返回5列，如果你的列数为17的话，那么就会获得四个Result实例，分别含有5,5,5,2个列。

下面会以表格的形式来帮助理解，假设我们拥有10Row，每个row拥有2个family，每个family拥有10个列。（也就是说每个Row含有20列）
caching batch Results RPCs Notes
1 1 200 201 额外的一个RPC是用来判断scan是否完成
200 1 200 2
2000 100 10 1 超过的部分没有用处，但是判断scan也在那一个RPC 中完成
2 100 10 6 10/2 +1 (额外的判断开销）
2 10 20 11
5 100 10 3
5 20 10 3
10 10 20 3

RPCs=(Rows* Cols per Row) / Min(Cols per Row, Batch size) / Scanner caching

上图引用自hbase权威指南，是用来表示一个RPC call的构成。
10.简述 HBASE 中 compact 用途是什么，什么时候触发，分为哪两种,有什么区别，有哪些相关配置参数？
　　在 hbase 中每当有 memstore 数据 flush 到磁盘之后，就形成一个 storefile，当 storeFile 的数量达到一定程度后，就需要将 storefile 文件来进行 compaction 操作。

Compact 的作用：

1>.合并文件

2>.清除过期，多余版本的数据

3>.提高读写数据的效率

HBase 中实现了两种 compaction 的方式：

minor and major. 这两种 compaction 方式的区别是：

1、 Minor 操作只用来做部分文件的合并操作以及包括 minVersion=0 并且设置 ttl 的过期版本清理，不做任何删除数据、多版本数据的清理工作。

2、 Major 操作是对 Region 下的 HStore 下的所有 StoreFile 执行合并操作，最终的结果是整理合并出一个文件。简述 Hbase filter 的实现原理是什么？结合实际项目经验，写出几个使用 filter 的场景HBase 为筛选数据提供了一组过滤器，通过这个过滤器可以在 HBase 中的数据的多个维度（行，列，数据版本）上进行对数据的筛选操作，也就是说过滤器最终能够筛选的数据能够细化到具体的一个存储单元格上（由行键，列名，时间戳定位）。 RowFilter、 PrefixFilter。。。hbase的filter是通过scan设置的，所以是基于scan的查询结果进行过滤.过滤器的类型很多，但是可以分为两大类——比较过滤器，专用过滤器过滤器的作用是在服务端判断数据是否满足条件，然后只将满足条件的数据返回给客户端；如在进行订单开发的时候，我们使用rowkeyfilter过滤出某个用户的所有订单

11.　Hbase 内部是什么机制
　　在 HBase 中无论是增加新行还是修改已有行，其内部流程都是相同的。 HBase 接到命令后存下变化信息，或者写入失败抛出异常。默认情况下，执行写入时会写到两个地方：预写式日志（write-ahead log，也称 HLog）和 MemStore。 HBase 的默认方式是把写入动作记录在这两个地方，以保证数据持久化。只有当这两个地方的变化信息都写入并确认后，才认为写动作完成。MemStore 是内存里的写入缓冲区， HBase 中数据在永久写入硬盘之前在这里累积。当MemStore 填满后，其中的数据会刷写到硬盘，生成一个 HFile。 HFile 是 HBase 使用的底层存储格式。 HFile 对应于列族，一个列族可以有多个 HFile，但一个 HFile 不能存储多个列族的数据。在集群的每个节点上，每个列族有一个 MemStore。大型分布式系统中硬件故障很常见， HBase 也不例外。设想一下，如果 MemStore 还没有刷写，服务器就崩溃了，内存中没有写入硬盘的数据就会丢失。 HBase 的应对办法是在写动作完成之前先写入 WAL。 HBase 集群中每台服务器维护一个 WAL 来记录发生的变化。WAL 是底层文件系统上的一个文件。直到 WAL 新记录成功写入后，写动作才被认为成功完成。这可以保证 HBase 和支撑它的文件系统满足持久性。大多数情况下， HBase 使用Hadoop 分布式文件系统（HDFS）来作为底层文件系统。如果 HBase 服务器宕机，没有从 MemStore 里刷写到 HFile 的数据将可以通过回放WAL 来恢复。你不需要手工执行。 Hbase 的内部机制中有恢复流程部分来处理。每台HBase 服务器有一个 WAL，这台服务器上的所有表（和它们的列族）共享这个 WAL。你可能想到，写入时跳过 WAL 应该会提升写性能。但我们不建议禁用 WAL，除非你愿意在出问题时丢失数据。如果你想测试一下，如下代码可以禁用 WAL： 注意：不写入 WAL 会在 RegionServer 故障时增加丢失数据的风险。关闭 WAL，出现故障时 HBase 可能无法恢复数据，没有刷写到硬盘的所有写入数据都会丢失。
12.HBase 宕机如何处理
答：宕机分为 HMaster 宕机和 HRegisoner 宕机，如果是 HRegisoner 宕机， HMaster 会将其所管理的 region 重新分布到其他活动的 RegionServer 上，由于数据和日志都持久在 HDFS中，该操作不会导致数据丢失。所以数据的一致性和安全性是有保障的。如果是 HMaster 宕机， HMaster 没有单点问题， HBase 中可以启动多个 HMaster，通过Zookeeper 的 Master Election 机制保证总有一个 Master 运行。即 ZooKeeper 会保证总会有一个 HMaster 在对外提供服务。

13.导致Hbase挂掉的场景
导致Hbase挂掉的场景
HMaster
HMaster会出现异常(执行abort())停止的场景如下：
1.zk异常导致的master停止服务是最常见的场景，涉及操作包含但不限于以下：
a)Zk链接超时，超时时间通过zookeeper.session.timeout配置，默认为3分钟, 如果fail.fast.expired.active.master配置的值为false（默认为false），则不会立即abort，而是会尝试恢复zk的过期session；
b)在打开region后，需要从zk中删除opened节点，如果zk有该节点，但是删除失败；
c)在split region过程中，从zk删除split节点时；
d)Master节点改变时；
e)从zk中创建unassigned节点时；
f)在下线disabled的regoin时，从zk中删除disabled的region如果发生zk异常；
g)还有很多操作zk的节点时如果出现异常。
2.在assign时，如果设置region为offlined状态，但是region之前的状态不是closed或者offlined；
3.在assign时，如果无法从.META.表中读取region信息；
4.把新的hbase集群加入到正在运行的hbase集群时，如果zk的/hbase/unassigned节点没有数据；
5.使用线程池批量分配region时，如果出现未被捕获的异常，实现方式如下：
6.在启动master的服务线程时，出现了异常；
7.在hdfs中检查hbase日志路径时，发现了dead的server时，需从hdfs中读出log，如果出现io异常需要检查hdfs文件系统，如果fsOk状态为true，但是通过FSUtils工具类进行检查时出现io异常；
8.在校验并且分配-ROOT-的region时，如果zk异常，或者其它异常（其它异常会重试10次），比如：“-ROOT- is onlined on the dead server”。

HRegionServer
HRegionServer会出现异常停止(执行abort())服务的场景如下：
1.在读写hdfs时如果出现IOException异常，此时会发起hdfs的文件系统检查（checkFileSystem）1.
2.Regionserver的服务线程出现了未捕获异常；
3.在启动HRegionServer时出现异常；
4.在进行HLog回滚时，出现异常；
5.在flush memstore时，如果持久化失败，会重启RS，在重启中把hlog的内容重新加载到memstore；
6.出现zk异常，包括但不限于以下场景：
a)Zk链接超时，超时时间通过zookeeper.session.timeout配置，默认为3分钟，与master不同，如果zk操作不会重试；
b)启动HRegionServer时出现KeeperException异常；
c)在进行split操作时，如果出现异常会进行回滚操作，在回滚过程中需要从zk中删除region的spliting状态，如果删除时出现KeeperException或者回滚的其它操作出现异常；
d)在打开region时，出现了KeeperException异常；
e)在进行hbase集群复制时，很多与zk交互的操作出现KeeperException异常时均会导致abort；
7.在close region时，如果出现异常，比如：不能成功的flush memstore；
8.Flush memstore时，如果HLog发现该region已经在flush则会强制终止JVM，采用的是Runtime.getRuntime().halt(1)方法，该方法不会执行正常退出的关闭钩子，从而不会flush RS的所有region，也不会迁移region，只有等待ZK的session超时后master才会发现该RS不可用，做迁移工作。

总结
Hbase挂掉的可能性有很多，主要由zk或者hdfs的问题导致，因此zk、hdfs的可用对于hbase极其重要，关于zk：
1.zk如果停止了服务则在很多时候会导致master、rs挂掉，hbase集群基本上就失去了服务的能力，因此zk一定要是稳定可靠的，当client已经于rs建立了链接，这时zk挂掉，如果不进行split等小数与zk交互失败会导致触发rs的abort()的操作时rs还是可以提供服务的；
2.如果rs/master进行了长时间的gc或者改动了服务器时间，导致出现zk的session超时会导致rs/master停止服务，目前已经出现了2次因为服务器时间变化导致hbase停止服务的事故;
3.别轻易人为改变zk的hbase节点数据，master/rs在进行很多操作时会比较依赖zk的数据，如果发现不符合预期可能会导致master/rs停止服务，尤其是master。
Master通过ZK知道RS是否可用，一般情况下RS在停止服务时均会正常退出，在正常退出时会从ZK中删除/hbase/rs/$regionserver的节点，Master会监听该节点的被删除，从而较快的(速度取决于所有region关闭时间)对该RS负责的region进行重新分配，如果是强制退出，比如 kill -9或者出现HRegionServer挂掉的第8条时则只有等待ZK的session超时时才会删除RS在ZK的节点（RS在ZK中添加节点时采用的是CreateMode.EPHEMERAL模式，该模式创建的节点会在session关闭时自动删除），那时Master才会进行重新assign。
Kill RS的进程也是正常退出（不能使用kill -9强制退出），RS使用Runtime的addShutdownHook方法注册了jvm关闭钩子，在关闭钩子中会执行RS的退出逻辑，实际上hbase-daemon.sh的停止RS就是采用kill。