HAProxy URI平衡不是很平衡

我不确定这是否有帮助，但是我也遇到了同样的问题 – 这正是我所得出的结论。

基于散列的负载平衡，就像你已经build立的一样，永远不会给你完美的负载平衡。 您所看到的行为可以简单地通过在同一台服务器上拥有几个最常访问/最大的页面来解释 – 通过几页获取大量stream量，以及获得很lessstream量的很多页面，这将足以歪曲统计。

你的configuration是使用一致的散列。 ID和服务器权重决定了散列条目将被引导到的最终服务器 – 这就是为什么你的平衡受到这个影响的原因。 文档很清楚，即使这是一个很好的平衡caching的algorithm – 它可能会要求您更改ID并增加服务器的总重量以获得更均匀的分布。

如果您抽取大量独特地址（超过1000个），并且您每次都访问这些地址 – 您应该看到，在三个后端中，会话计数器要比“普通”stream量对抗因为这也受到网站stream量模式的影响。

我的build议是确保你散列整个URL，而不仅仅是“？”的左边。 这是通过在configuration中使用balance uri whole来控制的。 参考。 haproxy文档 。 如果你有很多URL有相同的基础，但有不同的GET参数 – 这肯定会给你提供更好的结果。

我还会考虑负载平衡如何影响caching服务器的容量。 如果它不以任何方式有效地影响冗余 – 我不会担心太多，因为使用URI散列可能无法实现完美的负载平衡。

我希望这有帮助。

我最终改变了这样的configuration：

 backend varnish # hash balancing balance uri hash-type consistent server varnish1 64.106.164.122:80 check observe layer7 maxconn 5000 id 1 weight 75 server varnish2 64.106.164.121:80 check observe layer7 maxconn 5000 id 715827882 weight 50 server varnish3 64.106.164.117:80 check observe layer7 maxconn 5000 id 1431655764 weight 38 

事实certificate，身份证似乎很重要，我现在跨越这个范围，这似乎有助于平衡。 我调整了重量，你可以看到。

现在得到这样的结果：

中间的服务器仍然没有得到充分利用，但是我已经达到了平衡，这对我的目的来说很好。 我使用HAproxy做URI散列，所以我可以添加第三个清漆服务器，而不增加后端加载，它似乎运作良好，我看到后端加载与3个URI平衡清漆服务器vs两个随机平衡明显减less那些。

从这个意义上来说，身份证号码很重要，应该分开，这在其他地方我没有看到。 一旦ID被分散出来，改变权重会有所帮助，但它仍然是非常不可预测的，需要大量的调整和反复试验。 大幅度提高服务器的重量可能会导致stream量显着下降，这是一个奇怪的结果。