Serveur de jeu C ++ distribué qui utilise une base de données

11

Mon serveur de jeu au tour par tour C ++ (qui utilise une base de données) ne correspond pas au nombre moyen actuel de clients (joueurs), donc je veux l'étendre à plusieurs (plus d'un) quantité d'ordinateurs et de bases de données où tous les clients resteront encore monde de jeu unique (les serveurs doivent communiquer entre eux et utiliser plusieurs bases de données).

Existe-t-il des tutoriels / livres / normes communes qui expliquent comment le faire de la meilleure façon?

server databases

— slave
source

8

La terminologie MMO pour «rester dans un monde de jeu unique» est un fragment unique . EVE en ligne est le seul MMO majeur à tenter de bourrer chaque joueur en un seul fragment.

Heureusement pour vous, ils ont publié un article très instructif sur la façon dont ils le font.

_{(source: gamasutra.com )}

Les mauvaises nouvelles. Vous ne pouvez pas appliquer les techniques d'EVE en ligne en général. Leurs solutions sont absolument adaptées à leur genre et à leur mise en œuvre.
REMARQUE : pour tout le réseau de tesson unique super sophistiqué d'EVE Online, ils utilisent une seule base de données. Ils n'ont pas été en mesure de concevoir une solution évolutive, cohérente et modérément en temps réel pour les bases de données distribuées.

Dans tous les cas, lire comment ils l'ont fait devrait vous aider à concevoir votre propre solution. Attention cependant, vous essayez de résoudre un problème très difficile.

Au lieu de distribuer votre serveur de jeu, je suggère d'explorer d'abord vos autres avenues.

Profilez votre serveur de jeux.
- Optimisez le code de votre serveur pour réduire la charge du processeur en cas de problème.
- Optimisez le protocole de communication entre les clients et le serveur pour réduire les bavardages réseau.
Optimisez les communications entre le serveur gamer et la base de données.
- exécutez un optimiseur de requête, puis apportez les modifications appropriées.
- réduire l'interaction DB au strict minimum
Déplacez la base de données vers une machine distincte.
Cela aide souvent une tonne. Gardez la base de données sur le même réseau local si possible, mais cela devrait aider votre serveur de jeu à être beaucoup plus dynamique quand c'est la seule chose qui fonctionne sur le matériel du serveur.

— deft_code
source

Comment définissez-vous «majeur»? Kingdom of Loathing utilise un seul éclat. Tout le monde partage le même fragment Farmville. Star Trek Online et Champions Online utilisent tous deux un modèle à un seul fragment, mais des zones instanciées.

Au lieu d'utiliser une base de données SQL, vous pouvez également utiliser une solution noSQL conçue pour le clustering et le sharding, comme MongoDB.

— Philipp

1

Les jeux en ligne @JoeWreschnig ne sont pas des jeux en temps réel, beaucoup plus faciles ... Je ne sais pas combien de joueurs possèdent Star Trek Online et Champions Online ...

— o0 '.

4

Votre premier mouvement devrait être de découpler l'accès direct à la base de données du serveur de jeu et d'utiliser un middleware spécifique à l'utilisation pour préparer les données pour votre serveur (par exemple XML, JSON). Ceux-ci seraient capables de gérer n'importe quel nombre de bases de données et, plus important encore, de vous fournir des options de mise en cache spécifiques à l'application. Mettez tout ce que vous pouvez en cache et lancez la base de données uniquement lorsque vous le devez. Effectuez de grandes récupérations et rarement au lieu de nombreuses petites requêtes pour obtenir les meilleures performances possibles dans votre scénario.

La base de données de votre choix peut également vous permettre d'exploiter des clusters qui vous permettent d'étendre facilement les ressources de base de données disponibles et de fournir vos résultats plus rapidement, mais c'est un sujet qui nécessite beaucoup d'expérience et un administrateur de base de données dédié pour configurer et maintenir - et pas tout à fait pour le budget indépendant non plus.

— Konrad K.
source

1

Tout cela sonne bien jusqu'à ce que vous pensiez qu'il espère avoir plusieurs serveurs accédant à un seul ensemble de données - cela signifie que sans autre coordination, les caches côté application se désynchroniseront conduisant au mieux à des erreurs de jeu et à la perte de données au pire. Je ne suis pas en désaccord avec tout ce que vous avez dit, mais l'affiche originale devra également prendre en compte le problème de cohérence entre les serveurs avant de continuer.

— Kylotan

Le middleware est un tunnel de données qui est d'une part responsable de la mise en cache des données, mais également de la fourniture des données. Cependant, il fournit uniquement des données au serveur (jamais au client) et le serveur met en cache toutes les données de base liées au jeu au démarrage. Il peut donc y avoir de nombreuses sources de données et de nombreux demandeurs de données connectés à tout moment. Le MMO sur lequel je travaille utilise ce schéma assez efficacement.

— Konrad K.

Cela n'explique pas du tout comment vous avez résolu les problèmes de cohérence entre les serveurs. À un moment donné, les serveurs doivent synchroniser les données entre eux, ou vous avez des conditions de

Les données ne sont jamais dupliquées - à tout moment, un seul serveur est en charge d'un certain objet et, si nécessaire, il transmet cet objet à un autre serveur. Les objets sont des connexions client qui incluent également l'objet de contrôle du lecteur. Cependant, cela se fait via un serveur maître et est débattu entre les serveurs. Nous avons donc affaire à deux types de données - les informations de base de données (auxquelles se rapporte mon article d'origine) et les objets de jeu qui sont créés au moment de l'exécution et qui sont transmis dans un MMO multi-serveurs. Aucun de ces éléments ne doit jamais tomber dans une condition de concurrence ou être dupliqué au niveau de l'application.

— Konrad K.

3

Concernant le serveur de jeu: Une stratégie courante consiste à utiliser plusieurs serveurs où chaque serveur gère une partie du monde du jeu. Chaque utilisateur n'a généralement besoin que de savoir ce qui se passe autour de lui, il est donc logique de diviser le monde par localité. Cela devient malheureusement beaucoup plus compliqué lorsque vous avez un monde ouvert sans frontières au lieu d'un monde qui se compose de zones fermées et de téléporteurs entre eux. Lorsque vous avez un monde ouvert, vous avez besoin d'un moyen de transférer les joueurs entre les zones de manière transparente et d'un moyen de synchroniser les zones proches des frontières entre les serveurs. C'est un problème délicat.

Concernant la base de données: les bases de données SQL évoluent généralement mal. Ils ne sont pas conçus pour être distribués. Mais il existe actuellement une tendance plutôt nouvelle des bases de données NoSQL comme MongoDB ou Cassandra qui ont été conçues pour être distribuées sur plusieurs serveurs. Ils facilitent considérablement l'ajout de capacité en ajoutant simplement plus de serveurs. Alors pourquoi tous les grands jeux ne passent-ils pas à eux? Parce que:

Les bases de données SQL existent depuis plus de 40 ans, ces bases de données NoSQL depuis quelques années seulement. Il n'y a pas encore beaucoup de savoir-faire pour les utiliser plus efficacement et leur développement progresse rapidement. Il y a beaucoup de produits concurrents et totalement incompatibles sur le marché, et il n'y a aucun signe qui survivra et qui sera obsolète et abandonné dans quelques années. La plupart des grands acteurs préfèrent les lacunes connues de SQL aux risques inconnus des bases de données NoSQL.
Ils fonctionnent très différemment des bases de données SQL et nécessitent de repenser l'ensemble de votre stratégie de persistance. Cela peut entraîner des changements drastiques dans l'ensemble de votre architecture logicielle.

Ainsi, lorsque votre projet est déjà très avancé, le passage à une autre solution de base de données peut représenter un risque important et un très gros investissement en temps et en énergie.

— Philipp
source

0

Non. C'est un domaine incroyablement difficile qui n'a pas encore été résolu.

— Kylotan
source

Peut-être y a-t-il une solution "modèle" (pas comme "modèles de conception C ++)? Il y a beaucoup de MMORPG.

— Slav

2

La plupart des MMO sont soutenus par des catastrophes absolues pour les bases de données.

En particulier, les MMO ont souvent des approches très différentes de leur persistance des données, qui fonctionnent souvent de manière acceptable pour leur propre conception de jeu, mais pas pour d'autres conceptions de jeu. Étant donné que la conception du jeu est la partie la plus importante, vous ne pouvez pas spécifier correctement une stratégie de persistance et de distribution des données sans celle-ci. (Ce qui pourrait être interprété comme: "Posez une question plus spécifique, en nous disant quel type de données vous avez, à quelle fréquence elles changent et pourquoi vous pensez que vous voulez distribuer un seul monde sur plusieurs serveurs.")

— Kylotan

0

Je sais que c'est vieux mais ...

Il y a en fait deux domaines sur lesquels se concentrer.

Vous devez distribuer votre application sur plusieurs serveurs. Vous devez distribuer votre base de données sur plusieurs serveurs.

Et vous devez disposer d'une redondance pour les deux.

Il existe des solutions open source pour cela. Farmville est un bon exemple d'utilisation de MemSQL / Couchbase.

— KermEd
source

1

La distribution de la base de données sur plusieurs serveurs est certainement un problème résolu. Malheureusement, ce n'est généralement pas une exigence importante pour les jeux en ligne qui gardent leurs accès DB au minimum. En revanche, la distribution du gameplay réel sur plusieurs serveurs n'est toujours pas un problème résolu.

— Kylotan