我是haproxy的新手，并将其用于rsyslog日志到ArcSight连接器的TCP负载平衡。 在我的生活中，我无法使stream量在池中的所有节点之间均衡平衡（这是所需的行为）。 我已经尝试了许多重量和maxconn的排列无济于事。
感觉这应该是一个简单的问题，但是每个池节点的行为是非常混乱的。 而且，由于大多数人使用haproxy进行http负载均衡，所以我发现很less有关我正在尝试做什么的最佳方法。
任何人有任何见解，validationconfiguration或疑难解答步骤推荐？
谢谢！
这是我们目前的configuration：
global log 127.0.0.1 local0 log 127.0.0.1 local1 notice maxconn 256000 user haproxy group haproxy spread-checks 5 daemon quiet defaults log global option dontlognull option redispatch option allbackups maxconn 256000 timeout connect 5000 listen stats :1936 mode http stats enable stats realm Haproxy\ Statistics stats uri / stats auth admin:savetheday frontend rsyslog_netscreen bind 127.0.0.1:8514 mode tcp option tcplog option contstats option tcpka default_backend rsyslog_netscreen_backend backend rsyslog_netscreen_backend balance roundrobin mode tcp option tcpka option srvtcpka server netscreen1 localhost:9515 weight 1 maxconn 1024 check server netscreen2 localhost:9516 weight 1 maxconn 1024 check server netscreen3 localhost:9517 weight 1 maxconn 1024 check server netscreen4 localhost:9518 weight 1 maxconn 1024 check server netscreen5 localhost:9519 weight 1 maxconn 1024 check server netscreen6 localhost:9520 weight 1 maxconn 1024 check 请注意， roundrobin不是实现均匀负载的好策略。 它将确保每个后端接收相同数量的连接随着时间的推移，但不关心每个连接持续多久。
在你的stats视图中，显而易见，每个后端服务器的会话总数几乎相等（如果它们的运行时间相等）。 但是，当前会话的数量可能会有所不同。
我们发现使用leastconn而不是roundrobin产生更加均匀的负载。 这是有道理的，因为偶然发生的服务器被坚持连接的许多长生命的客户端所需，不需要为新的传入连接负担。
使用roundrobin进行短期连接，并使用leastconn进行相当长时间的连接。