前言

本文隶属于专栏《大数据技术体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！

本专栏目录结构和参考文献请见大数据技术体系

---

负载均衡

负载均衡是分布式系统的必备功能，多个节点组成的分布式系统必须通过负载均衡机制保证各个节点之间负载的均衡性，一旦出现负载非常集中的情况，就很有可能导致对应的部分节点响应变慢，进而拖慢甚至拖垮整个集群。

在实际生产线环境中，负载均衡机制最重要的一个应用场景是系统扩容。

分布式系统通过增加节点实现扩展性，但如果说扩容就是增加节点其实并不准确。

扩容操作一般分为两个步骤：

• 首先，需要增加节点并让系统感知到节点加入；
• 其次，需要将系统中已有节点负载迁移到新加入节点上。第二步负载迁移在具体实现上需要借助于负载均衡机制。

负载均衡从字面上来看就是通过一定策略使得整个系统的负载在所有节点上都表现均衡。

那首先需要明确系统负载是什么，应该通过哪些元素来刻画。

负载明确之后进一步检查集群的负载现状，如果已经均衡就不必做任何处理，如果不均衡就要制订负载迁移计划。

迁移计划制订之后需要根据计划进行具体负载的迁移。

---

负载均衡策略

HBase 官方目前支持两种负载均衡策略： SimpleLoadBalancer 策略和 StochasticLoadBalancer 策略。

---

1. SimpleLoadBalancer 策略

这种策略能够保证每个 RegionServer 的 Region 个数基本相等，假设集群中一共有 n 个 RegionServer，m 个 Region ，那么集群的平均负载就是 average = m/n，这种策略能够保证所有 RegionServer 上的 Region 个数都在 [floor(average)，ceil(average)]之间。

因此， SimpleLoadBalancer 策略中负载就是 Region 个数，集群负载迁移计划就是 Region 从个数较多的 RegionServer 上迁移到个数较少的 RegionServer 上。

很显然这种策略简单易懂，但是，考虑的因素太过单一，对于 RegionServer 上的读写 QPS 、数据量大小等因素都没有实际考虑，这样就可能出现一种情况：虽然集群中每个 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 迁移计划，使得代价值最小。

---

负载均衡策略的配置

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

<property> 
<name>hbase.master.loadbalancer.class</name> 
<value>org.apache.hadoop.hbase.master.balancer.SimpleLoadBalancer</value> 
</property>

---

3 .负载均衡相关的命令

HBase 提供了多个与负载均衡相关的 shell 命令，主要包括负载均衡开关 balance_switch 以及负载均衡执行 balancer 等命令。