Niedrige Latenz, groß angelegte Nachrichtenwarteschlangen

Question

Ich werde im Zeitalter der Facebook-Anwendungen und des Cloud Computing ein bisschen überzeugt von großflächigen Multiplayer-Spielen durchlaufen.

Angenommen, ich sollte etwas über vorhandene offene Protokolle bauen, und ich möchte 1.000.000 gleichzeitige Spieler bedienen, um das Problem zu umgehen.

Angenommen, jeder Spieler hat eine eingehende Nachrichtenwarteschlange (für Chat und so weiter) und im Durchschnitt eine weitere eingehende Nachrichtenwarteschlange (Gilden, Zonen, Instanzen, Auktion, ...), also haben wir 2.000.000 Warteschlangen. Ein Spieler hört 1-10 Warteschlangen gleichzeitig an. Jede Warteschlange hat durchschnittlich eine Nachricht pro Sekunde, aber bestimmte Warteschlangen haben eine viel höhere Rate und eine höhere Anzahl von Zuhörern (z. B. eine Warteschlange "Entitätsposition" für eine Ebene). Nehmen wir nicht mehr als 100 Millisekunden der Systemwarteschlangenlatenz an, was für leicht actionorientierte Spiele in Ordnung ist (aber nicht für Spiele wie Quake oder Unreal-Turnier).

Aus anderen Systemen weiß ich, dass es eine vernünftige Erwartung ist, 10.000 Benutzer in einer einzelnen 1U oder Blade -Box zu bedienen (vorausgesetzt, es gibt nichts anderes teuer, wie die Physiksimulation oder so weiter).

Mit einem Crossschel -Cluster -System, in dem Clients eine Verbindung zu Connection Gateways herstellen, die wiederum mit Messing Queue -Servern eine Verbindung herstellen, erhalten wir 10.000 Benutzer pro Gateway mit 100 Gateway -Maschinen und 20.000 Nachrichtenwarteschlangen pro Warteschlangenserver mit 100 Warteschlangenmaschinen. Wieder nur zum allgemeinen Scoping. Die Anzahl der Verbindungen auf jeder MQ -Maschine wäre winzig: ungefähr 100, um mit jedem der Gateways zu sprechen. Die Anzahl der Verbindungen auf den Gateways wäre viel höher: 10.100 für die Clients + Verbindungen zu allen Warteschlangenservern. (Fügen Sie darüber hinaus einige Verbindungen für Spiele -Simulationsserver oder so weiter hinzu, aber ich versuche, das vorerst getrennt zu halten.)

Wenn ich das nicht von Grund auf neu aufbauen wollte, müsste ich eine Messaging- und/oder Warteschlangeninfrastruktur verwenden, die existiert. Die beiden offenen Protokolle, die ich finden kann, sind AMQP und XMPP. Die beabsichtigte Verwendung von XMPP ist ein wenig eher dem, was dieses Spielsystem benötigen würde, aber der Overhead ist ziemlich spürbar (XML, plus die ausführlichen Präsenzdaten sowie verschiedene andere Kanäle, die oben aufgebaut werden müssen). Das tatsächliche Datenmodell von AMQP liegt näher an dem, was ich oben beschreibe, aber alle Benutzer scheinen große Unternehmensunternehmen zu sein, und die Workloads scheinen Workflows zu tun, nicht in Echtzeit-Spiel-Update im Zusammenhang.

Hat jemand Tageserfahrung mit diesen Technologien oder Implementierungen davon, die Sie teilen können?

Answer 1

@Msalters

Re 'Nachrichtenwarteschlange':

Der Standardvorgang von RabbitMQ ist genau das, was Sie beschreiben: transientes Pubsub. Aber mit TCP anstelle von UDP.

Wenn Sie eine garantierte letztendliche Lieferung und andere Ausdauer- und Wiederherstellungsfunktionen wünschen, können Sie dies auch haben - dies ist eine Option. Das ist der springende Punkt von Rabbitmq und AMQP - Sie können viele Verhaltensweisen mit nur einem Nachrichtenliefersystem haben.

Das von Ihnen beschriebene Modell ist das Standardverhalten, das vorübergehend, "Feuer und Vergessen" ist und Nachrichten dorthin weiterleiten, wo die Empfänger sind. Menschen verwenden Rabbitmq, um aus genau diesem Grund Multicast -Entdeckung auf EC2 zu machen. Sie können UDP -Typ -Verhalten gegenüber Unicast TCP PubSub erhalten. Ordentlich, oder?

Re UDP:

Ich bin mir nicht sicher, ob UDP hier nützlich wäre. Wenn Sie das Nagling ausschalten, wurde Rabbitmq Single-Meldung-Roundtrip-Latenz (Client-Broker-Client) mit 250-300 Mikrosekunden gemessen. Hier finden Sie einen Vergleich mit der Windows -Latenz (was etwas höher war) http://old.nabble.com/high%28er%29-latency-with-1.5.1-p21663105.html

Ich kann mir nicht viele Multiplayer -Spiele vorstellen, die Roundtrip -Latenz unter 300 Mikrosekunden benötigen. Sie könnten mit TCP unter 300US erreichen. TCP -Fenster ist teurer als rohes UDP, aber wenn Sie UDP verwenden, um schneller zu werden, und eine benutzerdefinierte Verlustrecovery oder SEQNO/ACK/RESEND Manager hinzuzufügen, kann dies Sie möglicherweise wieder verlangsamen. Es hängt alles von Ihrem Anwendungsfall ab. Wenn Sie wirklich wirklich UDP und faule ACKs usw. verwenden müssen, können Sie das TCP von Rabbitmq ausziehen und das wahrscheinlich abziehen.

Ich hoffe, dies hilft zu klären, warum ich Rabbitmq für Jons Anwendungsfall empfohlen habe.

Answer 2

Ich baue jetzt tatsächlich ein solches System.

Ich habe eine ganze Reihe von Bewertungen mehrerer MQs durchgeführt, darunter Rabbitmq, QPID und Zeromq. Die Latenz und der Durchsatz von diesen sind für diese Art von Anwendung mehr als ausreichend. Was jedoch nicht gut ist, ist die Warteschlangenzeit inmitten einer halben Million Warteschlangen oder mehr. Insbesondere qpid verschlechtert sich nach einigen tausend Warteschlangen ziemlich stark. Um dieses Problem zu umgehen, müssen Sie in der Regel Ihre eigenen Routing -Mechanismen erstellen (kleinere Anzahl der gesamten Warteschlangen, und die Verbraucher in diesen Warteschlangen erhalten Nachrichten, an denen sie kein Interesse haben).

Mein aktuelles System wird wahrscheinlich Zeromq verwenden, aber auf ziemlich begrenzte Weise, Innerhalb der Cluster. Verbindungen von Clients werden mit einer benutzerdefinierten SIM behandelt. Daemon, den ich mit Libev gebaut habe und völlig einzeln betränen ist (und zeigt eine sehr gute Skalierung-es sollte in der Lage sein, 50.000 Verbindungen auf einem Kästchen ohne Probleme zu handhaben-unsere Sim. Tick-Rate ist jedoch recht niedrig, und es gibt es Keine Physik).

XML (und daher XMPP) ist sehr nicht dafür geeignet, da Sie die CPU -Verarbeitung XML, lange bevor Sie an I/A gebunden sind, nicht so verarbeiten, was Sie nicht wollen. Wir verwenden im Moment Google -Protokollpuffer, und diese scheinen gut zu unseren besonderen Bedürfnissen geeignet zu sein. Wir verwenden auch TCP für die Client -Verbindungen. Ich hatte in der Vergangenheit Erfahrung mit UDP und TCP, und wie von anderen hervorgehoben wurde, hat UDP einen gewissen Vorteil, aber es ist etwas schwieriger, damit zu arbeiten.

Hoffentlich kann ich, wenn wir uns ein wenig näher am Start sind, weitere Details teilen.

Answer 3

Jon, das klingt nach einem idealen Anwendungsfall für AMQP und Rabbitmq.

Ich bin mir nicht sicher, warum Sie sagen, dass AMQP-Benutzer alle großen Unternehmenstyp-Unternehmen sind. Mehr als die Hälfte unserer Kunden befindet sich im "Web" -Raum von riesigen bis winzigen Unternehmen. Aus Rabbitmq wurden viele Spiele, Wettsysteme, Chat -Systeme, Twittery -Typ -Systeme und Cloud -Computing -Infräer aufgebaut. Es gibt sogar Mobiltelefonanwendungen. Workflows sind nur einer von vielen Anwendungsfällen.

Wir versuchen, den Überblick über das zu verfolgen, was hier vor sich geht:

http://www.rabbitmq.com/how.html (Stellen Sie sicher, dass Sie auch zu den Listen von Anwendungsfällen auf Del.icio.us klicken!)

Bitte schauen Sie sich an. Wir sind hier um zu helfen. Fühlen Sie sich gerne eine E -Mail an info@rabbitmq.com oder klicken Sie mich auf Twitter (@Monadic).

Answer 4

FWIW, in Fällen, in denen Zwischenergebnisse nicht wichtig sind (wie die Positionierung von Info), hat QPID eine "letzte Wertwarteschlange", die einem Abonnenten nur den neuesten Wert liefern kann.

Answer 5

Meine Erfahrung war mit einer nicht geöffneten Alternative, BizTalk. Die schmerzhafteste Lektion, die wir gelernt haben, ist, dass diese komplexen Systeme nicht schnell sind. Und wie Sie aus den Hardwareanforderungen festgestellt haben, führt dies direkt in erhebliche Kosten aus.

Aus diesem Grund gehen Sie nicht einmal XML für die Kernoberflächen in die Nähe. Ihr Servercluster analysiert 2 Millionen Nachrichten pro Sekunde. Das könnte leicht 2-20 GB/s XML sein! Die meisten Nachrichten werden jedoch für einige Warteschlangen erfolgen, während die meisten Warteschlangen tatsächlich niedrig mit dem Handel sind.

Entwerfen Sie daher Ihre Architektur so, dass es einfach ist, mit COTS -Warteschlangenservern zu beginnen und dann jede Warteschlange (Typ) auf einen benutzerdefinierten Warteschlangenserver zu verschieben, wenn ein Engpass identifiziert wird.

Gehen Sie aus ähnlichen Gründen auch nicht davon aus, dass eine Message Warteschlangenarchitektur für alle Anforderungen Ihrer Bewerbung am besten ist. Nehmen Sie Ihr "Entity -Standort in einem Instanz" -Beispiel. Dies ist ein klassischer Fall, in dem Sie nicht Wünschen Sie garantierte Nachrichtenzustellung. Der Grund, warum Sie diese Informationen weitergeben müssen, ist, dass sie ständig ändert. Wenn also eine Nachricht verloren geht, möchten Sie keine Zeit damit verbringen, sie wiederherzustellen. Sie schicken nur das alte Locatiom der betroffenen Einheit. Stattdessen möchten Sie das senden aktuell Standort dieser Entität. In Bezug auf technologische bedeutet dies, dass Sie UDP, nicht TCP und einen benutzerdefinierten Verlust-Recovery-Mechanismus wünschen.