Was ist die beste Serverarchitektur für Echtzeitspiele?

Ich entwickle ein Echtzeitspiel, das Tausende von Spielern in Echtzeit halten sollte (FPS wie max. 1s Verzögerung). Was wäre die beste Infrastruktur dafür?

Meine Idee war, zwei Servercluster zu verwenden - einen für das Serverende (die gesamte Computerseite) und einen für das Datenbandende, wobei ein Load Balancer für jeden der Cluster "verantwortlich" ist. Ein Hauptserver empfängt die Anforderungen von den Benutzern und sendet die IP-Adresse des entsprechenden Servers zurück, damit der Benutzer dies bearbeiten kann.

Der Datenbankcluster verwendet die Datenbankreplikation, um die Konsistenz zwischen den Datenbanken zu gewährleisten.

Es sollte auch einen geografischen Load Balancer geben, damit jeder Benutzer den regionalen Load Balancer erhält, um die bestmögliche Antwort zu erhalten.

Ich benutze .NET + MSSQL für das Spiel.

Vielen Dank!

server client-server .net

— römisch
quelle

Wenn Sie "Infrastruktur" sagen, meinen Sie damit Software, Hardware, Services oder wollten Sie nur, dass wir Ihren bestehenden Plan so wie er ist kritisieren?

— Tetrad

@Nate - Wir planen eine Skalierung, keine Duplizierung - daher sollte sie vollständig skalierbar sein.

— Roman

-1 weil teddziuba.com/2008/04/im-going-to-scale-my-foot-up-y.html - Sie decken keine Kapazitätsanforderungen ab, Sie sagen, das Spiel ist nicht gespalten, aber in Zonen unterteilt usw. Die Art der Leistungsoptimierung - einschließlich der Skalierbarkeit - erfordert spezifische Informationen, und es gibt keine absolut beste Architektur.

Ich würde Ihre Frage in etwas Konkreteres umformulieren. Was ist auf sachliche, nicht subjektive Weise das Beste? Meinen Sie am einfachsten zu skalieren, am einfachsten zu verwalten, am einfachsten in Gang zu bringen, am schnellsten oder was?

— Die kommunistische Ente

"Einfachste" ist auch subjektiv. Am einfachsten für wen, in welchem Zeitraum, mit welchen Ressourcen? Stack Exchanges funktionieren am besten bei bestimmten Fragen: "Ich habe diesen Server mit LINQ und MSSQL erstellt, aber er ist nach 70 Transaktionen / Sekunde umgefallen. Hier sind meine beiden Top-Transaktionen, die 73% meiner Laufzeit ausmachen. Wie soll ich meinen Durchsatz erhöhen?" ""

Antworten:

Es gibt keine beste Architektur, ohne viel mehr über Ihre Anforderungen zu wissen, z. die Art der Interaktionen zwischen Zeichen, wie viele Daten persistent sein werden und so weiter.

Wenn Sie mit einer Latenz von 1 Sekunde fertig werden, können Sie wahrscheinlich problemlos 1000 Spieler auf einem einzelnen Server hosten - dies widerspricht jedoch der Idee eines FPS, da diese normalerweise eine viel geringere Latenz erfordern, z. weniger als 100 ms. Ein System, das mit hoher Latenz umgehen kann, kann es sich jedoch leisten, alles über die Nachrichtenübermittlung zu erledigen, was die Konsistenz ziemlich trivial macht. Die Bereitstellung Ihrer Logik ist recht einfach, das heißt, komplexe Logik wird noch schlimmer, wenn Sie sie in ein nachrichtenbasiertes System anstatt in ein System mit gesperrten Objekten verwandeln - aber alles hängt von den Anforderungen Ihrer Anwendung ab.

Wenn Sie nicht viele Daten speichern, benötigen Sie den Datenbankcomputer überhaupt nicht, aber ohne das zu wissen, ist es schwer zu sagen. Wenn Sie kleine Datenmengen beibehalten und dies möglicherweise erst am Ende eines Turniers oder so tun, benötigen Sie wiederum keine separate Datenbank, schon gar nicht einen Cluster davon. Auf der anderen Seite können Ihnen die replizierten Datenbanken helfen, wenn Sie nicht viel beharrlich sind, sondern viel lesen. Dies zeigt jedoch auch, dass eine relationale Datenbank möglicherweise nicht die beste Lösung für Ihr Problem ist. Oft ist ein In-Memory-Cache eine bessere Lösung. In ähnlicher Weise wird die Konsistenz weniger wichtig, wenn keine Interaktionen im Transaktionsstil zwischen Zeichen vorhanden sind. (Und wenn es nur wenige solcher Transaktionen gibt, können Sie sie zu einem Sonderfall machen.)

Seien Sie in der Tat vorsichtig bei der Einführung eines RDBMS, nur weil dies in großen Systemen der Fall ist. Obwohl ich persönlich die Verwendung in Online-Spielen gutheiße, ist es am besten, Ihre Anforderungen zu betrachten und daraus Ihre Persistenzstrategie herauszufinden, anstatt Ihre bevorzugte Datenbank zu verwenden und dann zu versuchen, sie mit Caches und Replikationen zu optimieren, um sie an Ihre anzupassen App. Möglicherweise benötigen Sie lediglich Offline-Berichtsfunktionen. In diesem Fall ist es wahrscheinlich am besten, wenn ein Hintergrundprozess von Ihrem Spielpersistenzmechanismus in einem Remote-RDBMS an einem anderen Ort protokolliert wird.

— Kylotan
quelle

Haftungsausschluss: Meine Erfahrung in der Spielprogrammierung basiert auf clientseitigen Einzelspieler-Spielen, aber ich habe einen Hintergrund in Webanwendungen (speziell auf dem Microsoft-Stack). Daher denke ich, dass ich mit dieser Antwort von dort komme bewerben, aber ohne einen echten Spieleserver tatsächlich zu testen, ist es schwierig zu sagen, wie er angewendet wird, aber hier geht es weiter. Wissen Sie das: Ich habe keinen Spieleserver bereitgestellt, nur Webanwendungen.

Ich würde einen zweistufigen (Server-) Ansatz vorschlagen. Eine Datenbankebene und eine "Anwendungs" -Ebene; Die dritte (Präsentations-) Stufe ist Ihr Spielclient.

Relationale Datenbanken eignen sich hervorragend zum Abfragen von Daten und zum Schreiben von Daten. Der Schlüssel besteht darin, Ihre Datenbankschreibvorgänge in Blöcke mit überschaubarer Größe zu serialisieren, die Ihr Cluster verarbeiten kann. Die erweiterten Editionen (Rechenzentrum / Unternehmen) von SQL Server unterstützen Clustering und Replikation. Ich würde damit beginnen, einen kleinen Cluster zu erstellen und einige Abfragen dagegen auszuführen, um zu sehen, wie es funktioniert.

Wenn Sie in der Anwendungsebene "Zoning" oder ähnliches durchführen, können Sie wahrscheinlich davonkommen, ohne Cluster einzurichten, und einfach einen Server pro Zone einrichten. Wenn Ihre Zonen zu groß werden, können Sie für jede Zone einen Cluster einrichten.

Sie möchten einen Serialisierungsprozess zum Senden von Daten von der Anwendungsebene -> Datenbankebene erstellen. Der Schlüssel besteht darin, mehrere Serialisierungsebenen durchzuführen. So etwas wie das:

Stufe 1: Alle X Sekunden in der Datenbank speichern, enthält wichtige Daten:
- Spielergesundheit
- Spielergegenstände / Pickups
Stufe 2: Alle 2X Sekunden in der Datenbank speichern, einschließlich mittlerer Daten:
- Spielerstandorte
- NPC-Standorte
Level 3: Alles andere, so selten wie möglich

Auf diese Weise bleiben Ihre Schreibvorgänge konsistent und vorhersehbar. Abhängig von der Art Ihres Spiels kann es zu seltenen Datenbankschreibvorgängen kommen. Der Schlüssel ist zu erkennen, dass Sie bei einem Absturz Ihres Anwendungsservers aus dem Status in Ihrer Datenbank wieder online gehen müssen, sodass die Serialisierung des Spielerinventars alle 90 Minuten die Spieler verärgern kann.

Zum Lesen von Daten möchten Sie so viel wie möglich in den Speicher der Anwendungsebene laden und dann sicherstellen, dass Ihr gesamter Code diesen Speicherpool verwendet. Im Hintergrund können Sie den Speicherpool mit der Datenbank synchronisieren. Wie Joe betont, wird es Zeiten geben, in denen Sie "Echtzeit" -Transaktionen benötigen. Wenn Sie die meisten Ihrer Schreibvorgänge serialisieren, sollten Sie immer noch über genügend E / A in Ihrer Datenbank verfügen, um bei Bedarf Echtzeittransaktionen ausführen zu können, vorausgesetzt, die Hardware auf dem Datenbankserver / -cluster ist ausreichend.

— Nate
quelle

-1, weil Sie gerade ACID weggeworfen haben und die Datenbank nur als großen Datenspeicher verwenden. Das ist in Ordnung, der Windows-Festplattenplaner ist so beschissen, dass er immer noch einen Leistungsgewinn darstellt, und Sie können wahrscheinlich einige nette Offline-Metriken mit den darin enthaltenen Daten durchführen, aber Sie benötigen immer noch ACID - dh eine Datenbank -, die die Transaktionen im Spiel selbst unterstützt. in Echtzeit.

Das ist zwar spärlich, aber genau das habe ich im letzten Absatz angestrebt. Ich empfehle einen Hybrid, bei dem Sie nach Möglichkeit IN-Memory und bei Bedarf die Datenbank verwenden.

— Nate

Das Problem ist, dass Sie beschönigt haben, was sich im Speicher befindet, bei dem es sich um eine ganz andere Datenbank handelt, und dass Sie keine Anleitung zur Implementierung gegeben haben, was das eigentliche schwierige Bit ist.

Es stimmt, obwohl die Frage die Gesamtarchitektur und nicht die Implementierungsdetails betraf.

— Nate

Stimmt, aber Sie haben die gesamte Mittelschicht ausgelassen. Ist es eine RDB mit geringer Latenz? Eine ODB? Schlüssel- / Wertspeicher? Keine DB und ACID aufgeben? STM oder Verriegelung? Um fair zu sein, ist es sehr schwer zu beantworten, da die Frage nicht viele Informationen enthält, aber alles, was diese Antwort auf das Architekturdiagramm bewirkt, ist, die große Blase in der Mitte mit einem "?" drin und verbinde zwei weitere Dienste damit, nicht wirklich was "?" ist.