Druid中的负载均衡策略分析

在生产环境中，Druid查询通常能够命中多个（几十或几百个）segment。由于His节点的资源有限，所以segment需要被按照一定的策略均匀的分不到整个集群中，以确保集群的负载不会出现倾斜。

要确定最佳的负载分布，需要对业务，查询模式和速度有一定的了解。通常，Druid查询回复改一个独立数据源中最近一段临近时间的一批segment。总体来说，查询更小的segment速度更快。

通过以上，我们需要以更高的比率对历史segment进行复制，把大的segment以时间相近的形式分散到多个不同的His节点中。

对于实时索引服务，如何均衡的分配Peon，也关系到整个集群的性能。

实时负载均衡策略

这个负载均衡策略主要描述了Peon的分配策略：

• fillCapacity：集中在一台MiddleManager上分配Peon，当Peon的数量设置达到上限时，再在另一台MiddleManager上分配Peon。
• fillCapacityWithAffinity：配置Json格式的POST请求，指定DataSource到特定的MiddleManager机器上。
• equalDistribution：每台MiddleManager机器均匀分配Peon，即所有Peon平均分配。这种分配策略在机器配置都差不多时最适合。
• Javascript：通过自定义的Javascript函数来确定Peon的启动。
• AutoScalar：目前只有Amazon的EC 2支持。

His节点的负载均衡策略：

• CostBalancerStrategy：基于各种metric计算segments具体被哪个His节点加载。这么做的好处是负载很均匀，加入新的His节点后，能够把所有节点缓慢的调节到负载均衡的状态。但缺点是：计算很耗时，在某次线上测试中，总segments数量达到了37万，每小时生成2万左右segments的情况下，导致segments一直在waiting handoff，两天都没有handoff 完成。
• RandomBalancerStrategy：采用Java的Random（）方法，计算segment具体被哪个His节点加载。这么做的优点是：计算效率较高，现有节点基本能够均匀（差异百分比不会超过2%）负载到各个His节点上。但缺点也很明显：1）现有节点负载比较高时，新加入的节点不能自动重新分配。2）需要改代码重新编译。
• TierStrategy：分Tier加载。不同的业务线的DataSource加载到不同的Tier中。每个His节点只能属于一个Tier。负载均衡算法是在Tier内His节点上的负载均衡。这样能保证不同业务线之间的负载均衡不受影响。当增加新节点时，同一业务线内通过临时Tier调整负载均衡。操作过程是：加入新的His节点以后，先把Datasource所属的Tier设置为临时的Tier，然后等待到加载到临时Tier完成后，再切换回原来的Tier，这样逐步使整个业务线达到负载均衡。