[MySQL] Verrous et résolution d'action

[php_addict]

Une petite question concernent les job queue avec le couple Redis/Resque : Les données de la queue sont stockées en mémoire RAM et non en dur (ROM).

Est ce que je me trompe ? j'ai cru comprendre que les données de la RAM sont sauvegardées périodiquement en dur mais les crash serveur, process ou autre: ca ne pose pas de problème ?

sinon voici un article sur les LOCK et les transactions (apparemment ils ne formant pas un couple fiables):
http://dev.mysql.com/doc/refman/5.1/en/l...tions.html

[Sephi-Chan]

Tu as plusieurs politiques de persistance avec Redis (c'est configurable) : http://redis.io/topics/persistence.
La fréquence de sauvegarde peut notamment varier selon le nombre de clés modifiées (plus c'est actif, plus tu sauvegardes souvent). Cf. le fichier de configuration.

Donc oui, tu peux être niqué de quelques clés si ça crash.

[niahoo]

apres vu que ton jeu risque pas d'atteindre 10 000 joueurs le premier jour, redis sauvera sur le disque en quasi temps réel si tu le souhaites. Avec un systeme classique comme mysql tu peux également perdre des données en cours d'enregistrement. Et quand tu auras 10 000 joueurs tu pourras monter un systeme tolérant aux pannes (basiquement ta queue sera gérée simultanément par 2 PC ou plus, comme ça si un crash rien n'est perdu)

[Sephi-Chan]

C'est encore une fois une anticipation abusive des problèmes. ^^

Rendre un système entièrement fault-tolerant est complexe et très cher : la base de données, le serveur Web. Redis sera le cadet de tes soucis dans un tel cas.

[php_addict]

Une dernière petite question concernant les "job queue" si vous le permettez.

Quel est le temps de traitement du premier élément de la queue (en haut de la pile)? est ce quasi simultané? exemple:

- le joueur paye 500 monnaies virtuelles en cliquant sur "Payer"
- L'action du clic empile une nouvelle valeur dans la queue et le joueur est redirigé vers une page "vous avez payé"
- une fois redirigé est ce Resque/Redis as eu le temps de lancer le script php qui débite de 500 du compte du joueur ?

euh...je ne sais pas si c'est très clair...

sinon quelques liens pour les transactions et les lock:

http://www.montefiore.ulg.ac.be/services...tions.html
http://dev.mysql.com/doc/refman/5.0/fr/i...ation.html

Par défaut Mysql est en "REPEATABLE READ" ce qui peut occasionner des lectures de lignes fantômes, l'isolation innodb par défaut n'est donc pas très bonne mais semble satisfaisante quand peut d'accès concurrentiels se produisent, enfin je crois...

d'ailleurs je ne comprends pas pourquoi le niveau "READ UNCOMMITTED" existe car il n'isole rien du tout...

[Sephi-Chan]

Justement, avec les jobs queues tu n'as pas ce genre de garantie : ça peut être fait dans l'instant comme dans 30 secondes, comme dans 4 heures, selon le niveau de remplissage de ta queue.

Parfois si tu empiles beaucoup de tâches et que tu n'as pas assez de workers, tu as une grosse file d'attente. Pour remédier à ces problèmes, tu peux lancer plusieurs workers qui traitent toutes les queues et même des workers qui traitent seulement certaines queues (exemple : le lancement des parties).

[php_addict]

ok, et est ce que l'on peut trier la queue comme par exemple par 'timestamp' ou bien l'on est obligé de prendre le dessus du paquet ? (comme un push/pop en langage machine)

[Sephi-Chan]

C'est traité dans l'ordre dans lequel ça arrive à chaque worker.

[niahoo]

Sephi,
Il faudrait que l'action de débiter les 500 crédits en vérifiant que le joueur les a et de donner le bien acheté par le joueur au joueur se fasse dans la même transaction. Il faudrait donc que ce soit fait dans un seul et unique job de la queue, est-ce exact ?

En cliquant sur "acheter", le joueur serait redirigé vers une page qui "attendrait" que le job soit fini avant de le notifier au joueur. (ici utiliser de l'asynchrone serait vraiment un plus pour ne pas bloquer sur une page blanche plusieurs secondes). Il faut donc que ce soit rapide, donc je dirais utiliser une queue dédiée. Il faut également que ce soit atomique, donc Sephi, est-ce qu'en assignant un seul worker on peut s'assurer de ne pas avoir de race condition ?

[Sephi-Chan]

Effectivement, l'opération transactionnelle devra se faire dans une… transaction. Et a ce titre être dans un seul bout de code, qu'il soit exécuté dans un job ou non.

Ensuite, je ne pense pas qu'il soit utile de mettre cette opération dans un job, une poignée de SELECT et d'UPDATE se fait rapidement. Je partirais sur une simple requête XHR avec une petite image de chargement et un compte-rendu. Non ?