Je prévois de déployer une application à l'aide de la lecture et n'a jamais utilisé leurs "emplois" avant. Mon déploiement sera suffisamment grand pour exiger différents serveurs de jeu à la charge équilibrée, mais mes calculs ne seront pas assez grands pour avoir besoin de hadoop / tempête / autres.
Ma question est, comment puis-je gérer ce scénario en jeu? Si je configurais un travail en jeu pour courir chaque minute, je ne veux pas que chaque serveur fait exactement la même chose en même temps.
Je ne pouvais trouver que cette réponse mais je n'aime aucune de ces options.
Alors, existe-t-il des outils ou des meilleures pratiques pour coordonner les emplois ou dois-je faire quelque chose à partir de zéro?
3 Réponses :
Vous pouvez utiliser un drapeau de base de données comme décrit ici: Playframework'sworks Gestion des emplois concurrents par Pere Villega Pour deux emplois.
Mais je pense que la solution de Guillaume Bort sur Google Groupes à utiliser Memcache est la meilleure. Il semble y avoir un module pour la lecture 2: https://github.com/mumoshu/play2-Memcached < / a>
J'utiliserais personnellement un emploi d'une instance uniquement pour la simplicité. Sinon, vous pouvez regarder à l'aide d'AKKA au lieu d'emplois si vous souhaitez un contrôle plus fin sur l'exécution et une meilleure concurrence, une manipulation parallèle.
Vous pouvez utiliser une table dans votre base de données pour stocker un joblock, mais vous devez vérifier / mettre à jour ce verrou dans une transaction distincte (vous devez utiliser JPA.NewenTityManager pour cela)
My JOBLOCK CLASS utilise un LockMode Enum voici la classe de joblock p> et voici mon LockawareJOB qui utilise ce verrou p> log4j.logger.org.hibernate.event.def.AbstractFlushingEventListener=FATAL
Palako, avez-vous découvert la solution?
Salut Angelohk. Eh bien, oui, cette question est vraiment ancienne et, depuis lors, j'ai rencontré ce scénario plusieurs fois et j'ai appliqué différentes solutions sur mesure au problème, mais l'idée a toujours été la même, ce qui est autour d'une sorte de contrôle de la concurrence via verrouille dans une base de données. Différents moteurs de DB m'ont permis de faire différentes choses. Vous devez faire attention à la mise en œuvre, en ce qui concerne l'accès simultané à la DB pour la serrure elle-même (ou les serrures) des différents emplois de jeu.