Come ridurre al minimo i costi di rete del database di giochi distribuiti?

Question

Come ridurre al minimo i costi di rete del database di giochi distribuiti?

#1 da (1 voti)
#2 da (0 voti)

1

Abbiamo lavorato a un progetto di gioco online in rete che verrà eseguito nel prossimo futuro e alla ricerca di una soluzione soddisfacente per il nostro database di giochi distribuiti. Non abbiamo preso i costi di rete in considerazione finora.

Abbiamo i seguenti vincoli:

1) Abbiamo pianificato di utilizzare MySql ma possiamo esaminare le alternative se la soluzione offerta ha un senso.

2) Avevamo programmato di ospitare più server di gioco in diverse regioni geografiche come USA, Europa e Asia.

3) Ogni giocatore di solito si connette al server di gioco più vicino e al nodo di database distribuito per ridurre i costi e i ritardi di rete.

Abbiamo pensato di sviluppare una logica in uno dei nostri livelli lato server che controllerà la posizione dell'utente da cui vuole connettersi. Quindi, replica i dati specifici dell'utente da un nodo di database a un altro se l'operazione di controllo risulta che il giocatore tenta di connettersi da una regione diversa rispetto a prima.

Ci chiediamo che sia il modo corretto per farlo?

Ovviamente dobbiamo pensare ai casi di disastro. A tale scopo, cosa possiamo fare se uno dei nodi del database distribuito fallisce?

Non pensiamo di replicare tutti i dati tra i nodi del database perché causano elevati costi di rete.

Grazie

game-development mysql database-design distributed-computing cluster

posta aog 30.09.2014 - 23:52

fonte

2 risposte

1

Sembra un tipico utilizzo per una soluzione basata su bus di servizio.

Ho risolto esattamente questo problema, ma per mantenere attivi i server in esecuzione, interconnessi e sincronizzati tra loro nel mio framework del server MMO.

La semplice risposta è "non provare a sincronizzare i dati una volta che nel database usi un evento e gestiscili in più posizioni".

È fondamentalmente come adottare lo stesso approccio con cui il cloud computing ha più nuvole o hai bisogno di una pipe grassa su base pianificata o un mezzo per vedere una modifica incrementale mentre accade.

risposta data 01.10.2014 - 00:03

fonte

Leggi altre domande sui tag game-development mysql database-design distributed-computing cluster

Strategia per la memorizzazione di valori misti e tipi di riferimento senza box Utilizzo della dichiarazione lambda nella gestione delle eccezioni

score 0 · Accepted Answer

Eviterei qualsiasi replica di database ad-hoc, su richiesta. Idealmente, si desidera un singolo database utente coerente e logico su tutti i nodi, per scopi di emergenza.

@ La raccomandazione di Wardy su un bus di servizio è buona.

Non discuterò diverse architetture di cluster, ma affronterò il problema della larghezza di banda della rete e del volume delle transazioni.

Con i sistemi ad alto volume di transazioni, si incontra spesso un problema in cui c'è così tanto DML (o volume di transazione) che non è possibile eseguire la replica completa basata sulle transazioni; Un modo per ridurre la larghezza di banda complessiva della replica non è quello di replicare i registri delle transazioni, ma di eseguire la replica basata su snapshot in una frequenza di granularità ritardata e più ampia della frequenza media di aggiornamento del record. Chiamo questo coalescing o collassando il flusso ma non so se quei termini descrivono accuratamente riducendo il volume in questo modo.

Ad esempio, se il tuo player medio attivo registra aggiornamenti ogni 15 secondi sul suo nodo di database locale, puoi impostare un ciclo di replica di 10 minuti e associare 40 aggiornamenti medi per record in un singolo tiro di replica. Verranno trasmessi solo i record modificati dall'ultima estrazione e verrà replicato un singolo record anche se potrebbero esserci stati 40 aggiornamenti dall'ultima sincronizzazione. Ciò riduce il tuo potenziale volume di rete di un rapporto ovvio.

In questo modello, cose come il controllo basato sul trigger a livello di riga non funzionano perché non si ottengono tutte le transazioni, solo le ultime, quindi è necessario elaborarle nel progetto.

Per quanto riguarda le implementazioni, un buon esempio è Sybase iAnywhere Mobilink. Ma l'ho anche visto implementato in-house su diversi database di sapori.