在生產環境中，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，這樣逐步使整個業務線達到負載均衡。
