HBbase原理与实践_读书笔记_第八章 负载均衡实现

数据库集群负载均衡的实现依赖于数据库的数据分片设计，

可以在一定程度上认为数据分片就是数据读写负载，

负载均衡功能就是数据分片在集群中均衡的实现。

Hbase中的数据分片的概念就是Region，本章将介绍Region迁移、合并、分裂等原理

8.1 Region迁移

    分片迁移是最基础的核心功能，集群负载均衡、故障恢复等功能都是建立在分片的基础之上的。

    Hbase的Region迁移是一个非常轻量级的操作，因为Hbase 的实际数据存储在HDFS上，不需要独立进行管理，

    所以Region在迁移过程中不需要迁移实际的数据，只要将读写服务迁移即可。


    1.Region迁移流程

        region迁移复杂性表现在两个方面：

            1.Region迁移过程中涉及多种状态的改变

            2.迁移过程中涉及Master、ZK以及RegionServer等多个组件相互协调

        Hbase Region状态如下：

            状态              说明              状态          说明

            OFFLINE         下线             OPEANING      region正在打开
            OPEN          region正常打开      FAILED_OPEN   region打开失败
            CLOSEING      region正在关闭      CLOSED        region正常关闭
            FALED_CLOSE   regiong关闭失败     SPLITING      regio正在分裂
            SPLIT         region完成分裂      SPLTING_new   分裂产生新Region
            MERGING       region正在合并      MERGED        region完成合并
            MERGING_NEW   两个region合并成新的region  

            (打开 --- 合并/分裂 --- 关闭 )


        在实际执行过程中，Region迁移操作分两个阶段：unassign阶段 和 assgin阶段

            （1）unassign阶段
                unassign阶段表示Region 从 源RegionServer下线
                具体流程见书

            （2）assign阶段
                assign表示Region在目标RegionServer上线
                具体流程见书

8.2.Region合并

    相比Region 分裂,在线合并Region的使用场景比较有限。

    经典使用场景：使用在线合并功能将空闲Region与相邻的Region 合并,

    减少集群中空闲Region的个数，降低集群管理运维成本。
    
    Region合并的主要流程如下:

        1)客户端发送merge请求给Master。

        2)Master 将待合并的所有Region都 move 到同一个RegionServer上。

        3) Master发送merge请求给该RegionServer。

        4)RegionServer启动一个本地事务执行 merge操作。

        5)merge 操作将待合并的两个Region下线,并将两个Region的文件进行合并。

        6)将这两个Region从hbase:meta中删除,并将新生成的Region添加到hbase:meta中。

        7)将新生成的Region上线。

8.3 Region分裂

    Region分裂是Hbase最核心的功能之一

    Region分裂有多种触发策略可以配置，一旦触发就会寻找分裂点，然后执行真正的分裂操作。

1.Region分裂触发策略

        在当前版本中,HBase 已经有6种分裂触发策略。
        
        每种触发策略都有各自的适用场景 用户可以根据业务在表级别选择不同的分裂触发策略。
        
        常见的分裂策略有以下三种

            **ConstantSizeRegionSpliPolicy**

            **IncreasingToUpperBoundRegionSplirPolicy**

            **SteppingSplitPolicy**

        (1)ConstantsizeRegionSplirPolicy:
              
              0.94版本之前默认分裂策略。
              表示一个Region最大Store的大小超过设置阈值(hbase.hregion.max.filesize)之后会触发分裂

              ConstantsizeRegionSplitrPolicy最简单,但是在生产线上这种分裂策略却有相当大的弊端，
              分裂策略对于大表和小表没有明显的区分。
              
              阈值设置较大对大表比较友好,但是小表就有可能不会触发分裂,极端情况下可能就只有1个Region,这对业务来说并不是什么好事。

              如果阅值设置较小则对小表友好,但一个大表就会在整个集群产生大量的Region,对于集群的管理、资源使用来说都不是一件好事。

        (2)IncreasingToUpperBoundRegionSplitPolicy:
            
            0.94版本～2.0版本默认分裂策略。
            这种分裂策略总体来看和 ConstantSizeRegionSplitrolicy思路相同。

            一个Region中最大Store大小超过设置阈值就会触发分裂。
            但是这个阈值并不像ConstantSizeRegionSplitPolicy 是一个固定的值,而是在一定条件下不断调整,

            调整后的阈值 = (regions) * (regions) * (regions) *fush size*2,
            当然阈值并不会无限增大,最大值为用户设置的MaxRegionFileSize。

            这种分裂策略很好地弥补了 ConstantSizeRegionSplitPolicy 的短板,能够自适应大表和小表,
            而且在集群规模较大的场景下,对很多大表来说表现很优秀。

            然而,这种策略并不完美,比如在大集群场景下,很多小表就会产生大量小Region,分散在整个集群中。

        (3)SteppingSplirPolicy:
            
            2.0版本默认分裂策略。
            这种分裂策略的分裂阅值也发生了变化,相比 IncreasingToUpperBoundRegionSplitPolicy 简单了一些,

            分裂阈值大小 如果Region个数 = 1 ,分裂阈值 = fush size*2,否则 = MaxRegionFileSize。
            
            这种分裂策略对于大集群中的大表、小表会更加友好,小表不会再产生大量的小Region。

2.Region 分裂准备工作——寻找分裂点

        满足Region 分裂策略之后就会触发Region分裂。分裂被触发后的第一件事是寻找分裂点。

        所有有默认分裂策略,对于分裂点的定义都是一致的。当然,用户手动iorsPs可以指定分裂点进行分裂

        分裂点的定义为:
            整个Region中 最大Store中的 最大文件中 最中心的一个Block的 首个rowkey。

            如果定位到的rowkey是整个文件的首个rowkey  或者最后一个rowkey,则认为没有分裂点。

3.Region核心分裂流程

        HBase将整个分裂过程包装成了一个事务,目的是保证分裂事务的原子性。

        整个分裂备过程分为三个阶段:prepare、execute和rollback。操作模板如下:

            if(!st.prepare()) return;
            try{
                st.execute(this.server, this.server, user);

                success = true;
            }catch(Exception e){
                try{
                    st.rollback(this.server, this.server);

                } catch (IOException re){

                    string msg ="Failed rollback of failed split of parent.go-- aborting server";

                    LOG.info(msg, re);
                }
            }

        prepare、execute和rollback 具体流程见书

8.4Hbase负载均衡策略

    1.负载均衡策略

        HBse官方目前支持两种负载均衡策略:SimpleLoadBalancer 策略和 StochastilLoadBalancer策略。

        (1)SimpleLoadBalancer 策略

            这种策略能够保证每个RegionServer的Region个数基本相等,

            假设集群中一共有n个RegionServer, m个Region,那么集群的平均负载就是average =m/n,

            这种策略能够保证所有RegionServer上的Region个数都在[ floor(average), ceil(average)]之间。


            很显然这种策略简单易懂,但是考虑的因素太过单一,对于RegionServer上的读写QPA、数据量大小等因素都没有实际考虑,

            这样就可能出现一种情况:虽然集群中每个RegionServer的Region个数都基本相同,

            但因为某台Regionserver上的Region全部都是热点数据,导致90%的读写请求还是落在了这台RegionServer上

        (2)StochasticLoadBalancer策略

            StochasticLoadBalancer策略相比 SimpleLoadBalancer策略更复杂,

            它对于负载的定义不再是Region个数这么简单,而是由多种独立负载加权计算的复合值

            这些独立负载包括:

                ● Region个数(RegionCountSkewCostFunction)

                ● Region负载

                ●读请求数(ReadRequestCostFunction)

                ●写请求数(WriteRequestCostFunction)

                ● Storefile大小(StoreFileCostFunction)

                ●MemStore大小(MemStoreSizeCostFunction)●数据本地率(LocalityCostFunction)

                ●移动代价(MoveCostfunction)

            这些独立负载经过加权计算会得到一个代价值,系统使用这个代价值来评估当前Region分布是否均衡,越均衡代价值越低。

            HBase通过不断随机挑选送代来找到一组Region迁移计划,使得代价值最小。

    2.负载均衡策略的配置

        StochasticLoadBalancer是目前HBase默认的负载均衡策略。用户可以通过配置选择具体负载均衡策略