Server Architektur MMOPRG

[blabub]

Guten Abend zusammen


Ich bekam einen Auftrag für die Realisierung eines MMOPRG-Servers (OSS).
Das Projekt umfasst die alle Komponenten von Authentifizierung, über den Chat-Server, sowie das ganze Backend.
Die Anzahl der User wird sich zwischen 5000 - 25000 ansiedeln, eine Ausbaufähigkeit muss gegeben sein.

Bis jetzt hatte ich es immer mit zwei System zu tun, entweder über XML-Zugriff der Daten oder über eine Datenbank im Backend.

Ich möchte zu Testzwecken eine Hybrind-Lösung programmieren.


Achritektur 1:

http://www3.pic-upload.de/31.03.10/dtoagfopta1.png

Bei diesem Design würden alle Anfragen zuerst an den Main Node gehen, welcher dann die Lastaufteilung vornimmt und anschliessend die Arbeit an die Nodes weitergibt. Daher dient er als Durchschleifpunkt.

Die Nodes würden an sich die Daten abfragen und die Berechnungen vornehmen. Jeder Node würde sich ein Cache anlegen, in welchem er die Informationen z.B. über einen Charakter als XML-Datei speichert.

Der Lesezugriff würde dann so ablaufen:
Anfrage an Main Node
Weiterleitung an Node x
Node x liest alle Daten direkt aus dem XML, falls XML nicht vorhanden wird ein DB-Query abgesetzt aus welchem das XML anschliessend erstellt wird.

Der Schreibzugriff würde folgenden ablauf haben:
Anfrage an Main Node
Weiterleitung an Node x
Atomares commit auf Datenbank und XML (möglicherweise nur Datenbank, da ich sonst zu viel I/O erzeuge)

Probleme:
I/O welche beim XML auslesen/schreiben passieren
Wartezeit bis XML-Cache angelegt ist
Validierung der XML-Integrität
Overhead von Main Node zu Node x

Die Wartezeit beim XML-Cache anelgen, würde ich so regeln, dass bei einem Login automatisch der Cache angelegt wird, sollte dieses längern dauern wird sich der Login dem entsprechend verlängern (wobei der Login immer länger dauern sollte als den Cache erstellen)


Achritektur 2:

http://www3.pic-upload.de/31.03.10/bpyys4gr4zd.png


Unterschiede:
Loadbalancer direkt bei Verbindung zu den Main Nodes
XML-Filesharecache auf Basis von SSD-Festplatten
Interaktive Nodes welche den Cache aufbereiten

In dieser Methode läuft ein Lesezugriff wie folgt ab:
Anfrage an LB
Weiterleitung an Main Node x
Zugriff auf XML-Cache
Falls XML-Cache Out-of-date (Darf nicht passieren) Anfrage an Node x, dieser setzt eine Datenbankabfrage ab und aktualisiert den XML-Cache.


Der Schreibzugriff würde folgenden Ablauf haben:
Anfrage an Main Node x
Zugriff auf XML-Cache
Atomares commit auf XML, das XML ist so lange in einer Transaction bis Node x die Datenbank geupdated hat.
Update der Datenbank über Node x


Probleme:
I/O welche beim XML auslesen/schreiben passieren
Validierung der XML-Integrität
Overhead von Main Node zu Node x


Soviel zur Theorie, nun möchte ich mal nach Kritik nachfragen.
Ob dies so überhaupt Sinn macht und ob vlt. Probleme auftretten welche ich nicht berücksichtig habe.

Für jeglichen Input bin ich eigentlich sehr dankbar.


Gruss
blabub