Verteilter C ++ - Spieleserver, der eine Datenbank verwendet


11

Mein rundenbasierter C ++ - Spieleserver (der eine Datenbank verwendet) steht nicht der aktuellen durchschnittlichen Anzahl von Clients (Spielern) gegenüber. Daher möchte ich ihn auf mehrere (mehr als eine) Anzahl von Computern und Datenbanken erweitern, in denen sich noch alle Clients befinden einzelne Spielwelt (Server müssen miteinander kommunizieren und mehrere Datenbanken verwenden).

Gibt es einige Tutorials / Bücher / allgemeine Standards, die erklären, wie man es am besten macht?

Antworten:


8

Die MMO-Terminologie für "in einer einzigen Spielwelt bleiben" lautet " Single Shard" . EVE online ist das einzige große MMO, das versucht, jeden Spieler in eine einzelne Scherbe zu stopfen.

Zum Glück haben sie einen sehr informativen Artikel darüber veröffentlicht, wie sie es machen.


(Quelle: gamasutra.com )

Die schlechten Nachrichten. Sie können die Techniken von EVE online nicht generell anwenden. Ihre Lösungen sind absolut auf das jeweilige Genre und die jeweilige Implementierung zugeschnitten.
HINWEIS : Für alle Super-Fancy-Single-Shard-Netzwerke von EVE Online wird eine Datenbank verwendet. Sie waren nicht in der Lage, eine skalierbare, konsistente und mäßig Echtzeitlösung für verteilte Datenbanken zu entwerfen.

In jedem Fall sollte das Lesen, wie sie es gemacht haben, Ihnen helfen, Ihre eigene Lösung zu entwerfen. Beachten Sie jedoch, dass Sie versuchen, ein sehr schwieriges Problem zu lösen .

Anstatt Ihren Spieleserver zu verteilen, würde ich vorschlagen, zuerst Ihre anderen Wege zu erkunden.

  • Profiliere deinen Spieleserver.
    • Optimieren Sie Ihren Servercode, um die CPU-Belastung zu verringern, wenn dies ein Problem darstellt.
    • Optimieren Sie das Kommunikationsprotokoll zwischen den Clients und dem Server, um das Netzwerk-Chatter zu reduzieren.
  • Optimieren Sie den Spielerserver für die Datenbankkommunikation.
    • Führen Sie ein Abfrageoptimierungsprogramm aus und nehmen Sie die entsprechenden Änderungen vor.
    • Reduzieren Sie die DB-Interaktion auf ein Minimum
  • Verschieben Sie die Datenbank auf einen separaten Computer.
    Das hilft oft einer Tonne. Halten Sie die Datenbank nach Möglichkeit im selben lokalen Netzwerk, aber das sollte Ihrem Spieleserver helfen, viel schwungvoller zu sein, wenn es das einzige ist, was auf der Serverhardware ausgeführt wird.

Wie definieren Sie "Major"? Kingdom of Loathing verwendet eine einzelne Scherbe. Jeder teilt die gleiche Farmville-Scherbe. Star Trek Online und Champions Online verwenden beide ein Single-Shard-Modell, jedoch instanziierte Zonen.

Anstelle einer SQL-Datenbank können Sie auch eine noSQL-Lösung verwenden, die wie MongoDB für Clustering und Sharding entwickelt wurde.
Philipp

1
@ JoeWreschnig-Webspiele sind keine Echtzeitspiele, viel einfacher ... Ich bin mir nicht sicher, wie viele Spieler Star Trek Online und Champions Online haben ...
o0 '.

4

Ihr erster Schritt sollte darin bestehen, den direkten Datenbankzugriff vom Spielserver zu entkoppeln und eine nutzungsspezifische Middleware zu verwenden, um Daten für Ihren Server vorzubereiten (z. B. XML, JSON). Diese können eine beliebige Anzahl von Datenbanken verarbeiten und, was noch wichtiger ist, anwendungsspezifische Caching-Optionen bereitstellen. Zwischenspeichern Sie alles, was Sie können, und nörgeln Sie die Datenbank nur, wenn Sie müssen. Machen Sie große Abrufe und selten statt vieler kleiner Abfragen, um die bestmögliche Leistung in Ihrem Szenario zu erzielen.

Mit der Datenbank Ihrer Wahl können Sie möglicherweise auch Cluster betreiben, mit denen Sie die verfügbaren Datenbankressourcen problemlos erweitern und Ihre Ergebnisse schneller bereitstellen können. Dies ist jedoch ein Thema, für dessen Einrichtung und Wartung viel Erfahrung und ein dedizierter Datenbankadministrator erforderlich sind Nicht ganz für das Indie-Budget.


1
Dies klingt alles in Ordnung, bis Sie bedenken, dass er hofft, dass mehrere Server auf einen Datensatz zugreifen. Dies bedeutet, dass anwendungsseitige Caches ohne weitere Koordination nicht mehr synchron sind, was bestenfalls zu Spielfehlern und im schlimmsten Fall zu Datenverlust führt. Ich bin mit nichts, was Sie gesagt haben, nicht einverstanden, aber das Originalposter muss auch das serverübergreifende Konsistenzproblem berücksichtigen, bevor Sie fortfahren.
Kylotan

Die Middleware ist ein Datentunnel, der einerseits für das Zwischenspeichern von Daten und auch für die Bereitstellung von Daten verantwortlich ist. Es werden jedoch nur Daten für den Server bereitgestellt (niemals für den Client), und der Server speichert beim Start alle spielbezogenen Stammdaten zwischen. Es können also jederzeit viele Datenquellen und viele Datenanforderer verbunden sein. Das MMO, an dem ich arbeite, verwendet dieses Schema ziemlich effizient.
Konrad K.

Das erklärt nicht, wie Sie serverübergreifende Konsistenzprobleme überhaupt gelöst haben. Irgendwann müssen die Server Daten untereinander synchronisieren, oder Sie haben Rennbedingungen, die sich in zufälligen Verbindungsabbrüchen, doppelten Spielern, betrogenen Gegenständen, fehlenden Quests usw.

Daten werden niemals dupliziert - es gibt immer nur einen Server, der für ein bestimmtes Objekt verantwortlich ist, und bei Bedarf wird dieses Objekt an einen anderen Server übergeben. Objekte sind Clientverbindungen, die auch das Player-Steuerobjekt enthalten. Dies erfolgt jedoch über einen Master-Server und wird zwischen den Servern diskutiert. Wir haben es also mit zwei Arten von Daten zu tun - Datenbankinformationen (auf die sich mein ursprünglicher Beitrag bezieht) und Spielobjekte, die zur Laufzeit erstellt und in einem Multi-Server-MMO weitergegeben werden. Keines davon sollte jemals in einen Rennzustand geraten oder auf Anwendungsebene dupliziert werden.
Konrad K.

3

In Bezug auf den Spieleserver: Eine übliche Strategie besteht darin, mehrere Server zu verwenden, auf denen jeder Server einen Teil der Spielwelt verwaltet. Jeder Benutzer muss normalerweise nur wissen, was um ihn herum passiert. Daher ist es sinnvoll, die Welt nach Orten zu unterteilen. Dies wird leider viel komplizierter, wenn Sie eine offene Welt ohne Grenzen haben, anstatt einer Welt, die aus geschlossenen Zonen besteht und zwischen denen sich Spieler teleportieren. Wenn Sie eine offene Welt haben, benötigen Sie eine Möglichkeit, Spieler nahtlos zwischen Zonen zu übertragen und die Bereiche in der Nähe der Grenzen zwischen den Servern zu synchronisieren. Das ist ein heikles Problem.

In Bezug auf die Datenbank: SQL-Datenbanken skalieren normalerweise schlecht. Sie sind nicht für die Verteilung vorgesehen. Derzeit gibt es jedoch einen ziemlich neuen Trend bei NoSQL-Datenbanken wie MongoDB oder Cassandra, die für die Verteilung auf mehrere Server konzipiert wurden. Sie erleichtern das Hinzufügen von Kapazität erheblich, indem nur weitere Server hinzugefügt werden. Warum wechseln nicht alle großen Spiele zu ihnen? Weil:

  1. SQL-Datenbanken existieren seit über 40 Jahren, diese NoSQL-Datenbanken nur für einige Jahre. Es gibt noch nicht viel Know-how, wie man sie am effizientesten einsetzt, und ihre Entwicklung schreitet rasant voran. Es gibt viele konkurrierende und völlig inkompatible Produkte auf dem Markt, und es gibt keine Anzeichen dafür, welche davon überleben und welche in einigen Jahren veraltet und eingestellt sein werden. Die meisten Big Player bevorzugen die bekannten Mängel von SQL gegenüber den unbekannten Risiken von NoSQL-Datenbanken.
  2. Sie funktionieren ganz anders als SQL-Datenbanken und erfordern ein Überdenken Ihrer gesamten Persistenzstrategie. Dies kann zu drastischen Änderungen in Ihrer gesamten Softwarearchitektur führen.

Wenn Ihr Projekt bereits sehr weit fortgeschritten ist, kann der Wechsel zu einer anderen Datenbanklösung ein großes Risiko und einen sehr großen Zeit- und Energieaufwand darstellen.


0

Nein, dies ist ein unglaublich schwieriger Bereich, der noch nicht gelöst wurde.


Möglicherweise gibt es eine "Vorlage" (nicht als "C ++ - Entwurfsmuster) -Lösung dafür? Es gibt viele MMORPGs.
Slawischer

2
Die meisten MMOs sind durch absolute Katastrophen für Datenbanken abgesichert.

Insbesondere haben MMOs häufig sehr unterschiedliche Ansätze für ihre Datenpersistenz, die häufig für ihr eigenes Spieldesign akzeptabel sind, jedoch nicht für andere Spieldesigns. Da das Spieldesign der wichtigste Teil ist, können Sie eine Strategie für Datenpersistenz und -verteilung ohne eine nicht ausreichend spezifizieren. (Dies könnte so ausgelegt werden: "Stellen Sie eine spezifischere Frage und teilen Sie uns mit, welche Art von Daten Sie haben, wie oft sie sich ändern und warum Sie glauben, eine einzelne Welt auf mehrere Server verteilen zu wollen.")
Kylotan

0

Ich weiß, das ist alt, aber ...

Es gibt tatsächlich zwei Bereiche, auf die man sich konzentrieren muss.

Sie müssen Ihre Anwendung auf mehrere Server verteilen. Sie müssen Ihre Datenbank auf mehrere Server verteilen.

Und Sie müssen Redundanz für beide haben.

Hierfür gibt es einige Open Source-Lösungen. Farmville ist ein gutes Beispiel für die Verwendung von MemSQL / Couchbase.


1
Die Verteilung der Datenbank auf mehrere Server ist sicherlich ein gelöstes Problem. Leider ist dies normalerweise keine wichtige Voraussetzung für Online-Spiele, bei denen die DB-Zugriffe auf ein Minimum beschränkt sind. Im Gegensatz dazu ist die Verteilung des tatsächlichen Gameplays auf mehrere Server immer noch kein gelöstes Problem.
Kylotan
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.