Es ist möglich. Ziel ist es, mehrere eingehende Verbindungen parallel zu verarbeiten. Mehrere haproxy
Instanzen verwenden möglicherweise separate CPU-Kerne und arbeiten (halb) unabhängig voneinander. Eingehende Verbindungen werden an den Leerlauf übergeben haproxy
(sofern verfügbar), anstatt sich in der Warteschlange zu beschäftigen.
Ich denke haproxy
, Verwendungen SO_REUSEPORT
. man 7 socket
erklärt diese Option wie folgt:
SO_REUSEPORT
(seit Linux 3.9)Erlaubt, dass mehrere
AF_INET
oderAF_INET6
Sockets an eine identische Socketadresse gebunden werden. Diese Option muss an jedem Sockel (einschließlich des ersten Sockels) eingestellt werden, bevorbind(2)
der Sockel aufgerufen wird. Um das Port-Hijacking zu verhindern, müssen alle an dieselbe Adresse gebundenen Prozesse dieselbe effektive UID haben. Diese Option kann sowohl für TCP- als auch für UDP-Sockets verwendet werden.Bei TCP-Sockets kann mit dieser Option die
accept(2)
Lastverteilung in einem Multithread-Server verbessert werden, indem für jeden Thread ein eigener Listener-Socket verwendet wird. Dies bietet im Vergleich zu herkömmlichen Verfahren eine verbesserte Lastverteilung, z. B. die Verwendung eines Single-accept(2)
Thread, der Verbindungen verteilt, oder mehrere Threads, die mitaccept(2)
demselben Socket konkurrieren .
Überprüfen Sie auch SO_ATTACH_REUSEPORT_CBPF
und SO_ATTACH_REUSEPORT_EBPF
dort.
Edit: Ich fand diesen Artikel (vom 3. Mai 2017); es scheint meine Vermutung zu stützen:
Inzwischen wurde eine neue und wesentlich bessere
SO_REUSEPORT
Implementierung in den Linux-Kernel 3.9 eingeführt, wodurch die Last intelligent auf mehrere Sockets verteilt werden konnte. HAProxy könnte sofort von dieser neuen Verbesserung profitieren.Aber es kam mit einem Problem [...]
Mach dir keine Sorgen über das Problem. Der Artikel beschreibt Problemumgehungen und eine Lösung. Vielleicht finden Sie es interessant, wenn Sie sich für solche Sachen interessieren.