Discussion :

[youtpout978]

C'est pour ça je voulais faire de l'event driven design avec du CQRS, j'ai une bdd ou je fais juste de l’écriture (sur une bdd mongo db par exemple) et une autre pour la lecture ou j'ai juste les infos à jour (du genre mon player est lvl 15 il a tué 3000 monstres ...)
Normalement avec mes donnés sauvegarder je peux vérifier qu'il n'y a pas de triche et recréer les données de la table de lecture.

Après on peut se dire que c'est sortir le bazooka pour tuer une mouche, mais comme tout projet perso ça me permettra d'apprendre à utiliser de nouveaux outils, nouvelles technos ...

[Sebajuste]

Non c'est pas forcément un bazooka.

Car on peut récupérer beaucoup d'info utile ! N'as tu jamais vu ces "carte de chaleur" qui montrent où les joueurs meurts ? Ca permet clairement de mettre en évidence les zones les plus difficiles pour améliorer en continu l'équilibrage par exemple.

Par contre, j'éviterais les enregistrement en continue. On n'a pas besoin d'enregistrement en temps réel, et encore moins de transaction pour ce genre de chose.
Le modèle CQRS n'est pas forcément mauvais (même si je déconseilé de l'implémenter tel quel, ça ne serait pas adapté).

Mais l'idée est bien d'avoir un service d'enregistrement des évènements en BDD, qui écoute sur les bus les évènements des parties, afin de les enregistrer par batch.
Ca permet de dédier l'enregistrement à un seul service (quitte à en avoir plusieurs instance), où l'on peut régler le nombre de connexion, la fréquence d'écriture et la taille des batch de manière optimale.

Beaucoup de MMO ne sauvegardent les données des joueurs que de manière régulière. Ca ne t'ai jamais arrivé de perdre ta progression des dernières minutes après le crash du serveur de ton MMO préféré ?

Mais surtout, une telle archi ne ralentira pas les services qui calculent le jeu !

[youtpout978]

Non c'est pas forcément un bazooka.

Car on peut récupérer beaucoup d'info utile ! N'as tu jamais vu ces "carte de chaleur" qui montrent où les joueurs meurts ? Ca permet clairement de mettre en évidence les zones les plus difficiles pour améliorer en continu l'équilibrage par exemple.

Par contre, j'éviterais les enregistrement en continue. On n'a pas besoin d'enregistrement en temps réel, et encore moins de transaction pour ce genre de chose.
Le modèle CQRS n'est pas forcément mauvais (même si je déconseilé de l'implémenter tel quel, ça ne serait pas adapté).

Mais l'idée est bien d'avoir un service d'enregistrement des évènements en BDD, qui écoute sur les bus les évènements des parties, afin de les enregistrer par batch.
Ca permet de dédier l'enregistrement à un seul service (quitte à en avoir plusieurs instance), où l'on peut régler le nombre de connexion, la fréquence d'écriture et la taille des batch de manière optimale.

Beaucoup de MMO ne sauvegardent les données des joueurs que de manière régulière. Ca ne t'ai jamais arrivé de perdre ta progression des dernières minutes après le crash du serveur de ton MMO préféré ?

Mais surtout, une telle archi ne ralentira pas les services qui calculent le jeu !

Bein c'est le but en adoptant l'EDD, je pense que le temps réel avec des bdd tel que mongo doit être facilement réalisable, quand tu vois déjà les perfs de base sql server ...
Bein justement j'étais sur un MMO où tu pouvais faire crash le serveur afin de dupliquer des items

[Sebajuste]

Eh bien justement !

Si tu sauvegarde par batch, il n'y a pas de duplication possible (ou tout du moins limité). Alors que si tu sauvegarde en continu, si !


En effet, lors de la sauvegarde en continu, il faudra obligatoirement faire ces enregistrement en asynchrone.
Si on attends que la donnée soit effectivement écrite sur disque avant de renvoyer la réponse au client, la simulation va obligatoirement subir des lag.
Or, écrire des données de manière asynchrone, c'est se heurter aux problèmes de concurrence. Il est donc tout aussi possible de dupliquer des objets, que de les perdre...


A l'inverse, si on regroupe les événements pour les -batcher-, on va pouvoir écrire en une seule fois toute une série de modifications. L'enregistrement de toute la série est donc atomique !
L'avantage d'un service dédié à l'enregistrement est donc de pouvoir s'assurer que les batchs soit sauvegardé de manière séquentiel, même si les événements sont envoyés à ce service de manière asynchrone ( c'est une transaction coté logiciel en quelque sorte).

Alors clairement, il ne s'agit pas d'un respect strict des propriétés ACID, mais ça permet de s'y rapprocher.

[youtpout978]

A voir une fois en place, je suis pas sur que dans mon cas le lag soit perturbant c'est du tour par tour, je peux comprendre que sur un action-rpg ça soit gênant ...