Recommandé
Recommandé
Contenu connexe
Similaire à Cocktail temps reel pour l’olympia
Similaire à Cocktail temps reel pour l’olympia (20)
Cocktail temps reel pour l’olympia
- 1. COCKTAIL TEMPS-REEL POUR L’OLYMPIA COCKTAIL TEMPS-REEL POUR L’OLYMPIA
- 2. Qui suis-je ? Amélie DUVERNET - www.amelieonline.net ● Développeur R&D chez Digitick ● Auto-entrepreneur ● Membre de l’AFUP Marseille-Aix - marseille.afup.org @bonjouramel
- 3. Digitick Digitick c’est : ● Leader de la vente de billets en ligne ● Concerts, expositions, musées, sport ... ● Création en 2004 ● 35 millions de billets vendus par an
- 4. Digitick : notre métier Avant ● preparatifs pour la vente : vente en ligne ... Pendant ● vente sur place avec guichets ● contrôle d’accès Après ● rapports de vente ● reporting ● comptabilité
- 5. Pôle Recherche et Développement ● Développement : outils internes, optimisation performances, couche technique, core ● Expertise : architecture, veille technologique, partage d’experience ● Intégration continue : MEP, déploiement d’outils annexes, intégration continue
- 6. LE BESOIN
- 7. Besoin client ● Taux temps-reel de remplissage d’une salle ● Afficher les espaces vides dans la salle ● Pouvoir replacer les clients
- 8. L’Olympia ... C’est … ● + de 100 ans de spectacles ● + 1700 places ● Les plus grands artistes sur scène UN GROS CLIENT !!! Credit pho to : https: //www.flickr.co m/pho to s/547 00909@ N03/32508 1 7 1 51 2
- 9. Enjeux techniques ● Notification temps-réel occupation siège ● Diffuser à des observateurs connectés à des moments differents ● Echelonnabilité (scalabilité) ● Sécurité ● Fiabilité ● Front dynamique ● Performance
- 10. La mission ● Afficher le plan de la salle ● Changer l’apparence du siège lors du compostage ● Nombre de personnes ● 5 derniers compostages (notifications)
- 11. Les problématiques ● Affichage des sièges déjà compostés ● Temps-réel ● Correspondance spectacle <-> billet ● SÉCURITÉ ! ● Effacement des données
- 12. PHP ET TEMPS-REEL ! WHAT ?
- 13. CE QUI EXISTAIT
- 14. Nos outils internes ● Application embarquée de contrôle d’accès TR ● Communication PHP vers MySQL ● Mise à jour du billet -> composté ● Plan de salle Olympia : Symfony2 + AngularJS
- 15. Nous utilisons aussi ... ● RabbitMQ ● Redis ● NodeJS Et nous aurons besoin de : Websockets !
- 16. SHAKE IT !
- 17. Le cocktail
- 18. LES INGREDIENTS
- 19. PHP ● Obtention des informations ● Envoi des compostages ● Attribution et vérification des tokens ● Chargement des données du plan
- 20. PHP ● Obtention des informations ● Envoi des compostages ● Attribution et vérification des tokens ● Chargement des données du plan SECURITE
- 21. Redis ● Stockage des listes de compostage ● Stockage des billets ● Stockage des tokens
- 22. Redis ● Stockage des listes de compostage ● Stockage des billets ● Stockage des tokens PERFORMANCE
- 23. RabbitMQ ● Notifications au serveur ● Désempilage au fur et à mesure
- 24. NodeJS ● Daemon de recupération des compostages ● Acquittement des compostages traités ● Contrôle token securité
- 25. Socket.io (serveur) ● Gestion des rooms ● Notification des sockets ● Keep-alive
- 26. Socket.io ● Gestion des rooms ● Notification des sockets ● Keep-alive NOTIFICATIONS TEMPS REEL
- 27. AngularJS ● Le plan ● Récupération des données ● Connexion websocket ● Initialisation du token-securité ● Gestion des pertes de connexion ● Gestion du numéro d'ordre
- 28. AngularJS ● Le plan ● Récupération des données ● Connexion websocket ● Initialisation du token-securité ● Gestion des pertes de connexion ● Gestion du numéro d’ordre FRONTDYNAMIQUE
- 30. Les données importantes ● Date et heure de compostage ● Code barre du billet ● Nom du bloc ● Rang du siège ● Numero de siège
- 31. Nos listes ● Valeurs ordonnées dans un “set” ● Correspondance avec la clé définie ● Récupération avec des intervalles de temps 00012 123 00052 00023 00123 00055 + time() + time() + time() + time() ZADD N° ordre REDIS N° spectacle N° siège
- 32. Notre siège ● Infos complémentaires au compostage ● Stockées en HASH dateHeure idSpectacle:idSiege codeBarre nomBloc rangSiege numeroSiege HASH REDIS
- 34. Récupération des compostages Plan RequêteHTTP (+num ordre) Notification 1 Notification 2 Notification 3 Notification 4 Notification 5 Affectés Vendus Compostés++ Redis Notification 6 Interfaced’affichage
- 35. ECONOMIE DE RESSOURCES Activation du compostage
- 36. Le Token-Activation ● Associé au spectacle ● Stocké dans Redis ● Permet les notifications à RabbitMQ ● Crée par le plan ● Vérifié lors du compostage
- 37. LA SECURITE ! Ai-je le droit de voir les compostages de ce plan ?
- 38. Token Securité (écoute) Admin 1 - Token xxx 2 3 - Token xxx 4 – Token check
- 39. Sur le plan socket.on('connect', function() { dataAccess.get('generateToken', {}, function(success, response) { // Création du token if (success == true) { socket.emit('subscribe', { token: response.token, idSpectacle: idSpectacle }); // Envoi du token } else { console.log("Erreur generation token."); } }); });
- 40. Sur NodeJS socket.on('subscribe', function(showInfos) { // Message envoyé depuis le client JS, contient le token + spectacle id http.get(config.checktoken +'/'+ showInfos.token, function(data){ if(data == 'true') { var myRoom = 'show' + showInfos.idSpectacle; socket.join(myRoom); // Rejoint la room } else { console.info('[' + tsHmsConnex + '] Token inconnu. Connexion refusee, abandon representation ' + showInfos.idSpectacle + ' avec token ' + showInfos.token); } }); });
- 41. PERTE DE CONNEXION ?
- 42. En cas d’urgence ● Bascule sur des appels Ajax réguliers ● Rebascule automatiquement sur la websocket
- 43. DEMO
- 46. Création de rooms U4 Room idSpectacle1 U1 U2 U3 Room idSpectacle2 Socket Notification Principe d’ un canal IRC
Notes de l'éditeur
- Comment introduire : c’est bientôt l’hiver, et comme tous les hivers nous avons besoin de vitamines. L’an dernier, c’est l’Olympia qui a eu besoin de vitaminer son système de gestion des places en voulant y intégrer un système d’affichage temps-réel des places ! C’est la recette d’un hiver chargé que nous allons découvrir ;) !
- Parler de mon expérience : je suis dans le php depuis à peu près 15 ans, développeur certifiée pour l’anecdote. Je suis également auto-entrepreneur quand je m’ennuie chez moi. Sinon je suis également étudiante en photo : à la pause si vous n’avez pas envie de coder, je vous suggère d’aller sur ce site : ce sont des reportages sur des lieux abandonnés, un projet qui me tient à coeur, il y a de superbes photos. Si il y a des marseillais dans la salle, je les informe que l’afup dispose de son antenne dans la région.
- Ici j’embraye sur ma société-à-moi la digipassion.
- C’est parti d’un après-midi, mes chefs m’ont appelée dans leur bureau. Et là je me dis : oui ? que se passe-t-il ? Ils avaient le sourire … Et là ils me disent : “on va te confier le projet temps réel de l’Olympia” Cool.
- Préciser le cadre de l’olympia : histoire etc ...
- Ici il faut parler plus précisément du résultat attendu par le client : Afficher le plan de la salle : Déjà la salle telle qu’elle est représentée lors du concert Parler des filtres Afficher le compostage du siège : changement d’apparence en temps réel Connaître le nombre de personnes : Affichage du nombre de vendus Affichage du nombre de personnes que peut contenir la salle Affichage du nombre de billets compostés Connaître les données des 5 derniers compostages : le nom, le prenom, le numero de siège et le positionnement.
- A cela s’ajoute quelques éléments non négligeables : il est facile d’envisager l’affichage en temps-réel, il faut également récupérer pour une représentation déjà commencée les sièges qui ont déjà été compostés pour les afficher Il faut également penser que le billet est affilié à une représentation, ce qui est logique. Et là, il faut penser cette contrainte peut entraîner des problèmes de sécurité : il faut être sur que les informations, lors du compostage, passent bien dans le canal du plan correspondant ! Une fois que la représentation est terminée, les données de compostages ne servent plus à rien
- Je sais ce que certains vont dire … pour faire du temps réel en php, c’est même plus de la cuisine, c’est de la chimie !!! Pas tant que ça en fait … le langage seul ne sera pas suffisant ! Il va donc falloir utiliser des outils en plus … certainement du Javascript, mais pas que !
- Chez Digitick, il existait déjà un système de compostage basique. A base d’une douchette, on scanne le billet et les données sont enregistrées en base pour être réutilisées. C’est à partir de cette base que je vais pouvoir travailler tout autour.
- C’est tout simple. Le visiteur donne son billet, qui est déjà enregistré dans la base de données en MySQL. Un script PHP est exécuté pour mettre à jour les données du billet, entre autres sa date et son heure de compostage. Il y avait également le projet de gestion de l’Olympia qui venait de sortir, mais sans temps-réel, avec juste le plan, pour permettre de gérer les différentes configurations suivant les concerts. Le projet est conçu en SF2 et en AngularJS.
- Hors processus de compostages, ils y a des noms qui circulent tout autour du service R&D … c’est comme ça que les noms, RabbitMQ, pour gérer les notifications, Redis, base de données NoSQL, et NodeJS circulent … Et il en manque un … pour assurer vraiment la cohésion et le temps réel : sockets.io Ces éléments ajoutés au système pourraient bien faire un bon cocktail explosif !
- Ensuite, PHP sera le rhum du Mojito, c’est là que le plus important de base. C’est avec lui que je vais agrémenter le script APPS4 pour “picorer” les informations dont j’ai le plus besoin pour les envoyer à une autre base de données plus légère qui me permettra de traiter mes compostages temps-reel.. Je vais envoyer à cette base mes listes de billets : en effet, APPS4 envoie au serveur des listes de billets à la volée. Je vais donc envoyer cette liste + des séries de tableaux plus détaillés par id envoyé dans la liste. Ensuite je vais utiliser PHP pour créer mes tokens Et puis je vais configurer mes sockets.
- Ensuite, PHP sera le rhum du Mojito, c’est là que le plus important de base. C’est avec lui que je vais agrémenter le script APPS4 pour “picorer” les informations dont j’ai le plus besoin pour les envoyer à une autre base de données plus légère qui me permettra de traiter mes compostages temps-reel.. Je vais envoyer à cette base mes listes de billets : en effet, APPS4 envoie au serveur des listes de billets à la volée. Je vais donc envoyer cette liste + des séries de tableaux plus détaillés par id envoyé dans la liste. Ensuite je vais utiliser PHP pour créer mes tokens Et puis je vais configurer mes sockets.
- Redis pour ceux qui ne savent pas est un système de base de données NoSQL. Du coup on peut lui envoyer plein de format de données : des listes, des tableaux, des strings etc … il suffit de lancer la commande appropriée. Les données sont juste stockées sous un système de clé valeur, pour permettre au système de retrouver une donnée correspondante à une clé. On peut stocker les données d’un billet avec une clé id. Mais aussi du coup, on peut par exemple affecter comme clé un offset time … pratique par exemple pour envoyer une liste avec un tel offset, ça permet de récupérer les id des billets qui n’ont pas encore été traités. On peut donc dire au système : “retrouve moi les id des billets qui ont été compostés ces trois dernières minutes !” Et après, retrouver les données des billets grâce aux ids. Redis ne sera pas utilisé tout seul. Ce sera PHP qui exécutera les commandes REDIS grâce à la bibliothèque PRedis.
- Redis pour ceux qui ne savent pas est un système de base de données NoSQL. Du coup on peut lui envoyer plein de format de données : des listes, des tableaux, des strings etc … il suffit de lancer la commande appropriée. Les données sont juste stockées sous un système de clé valeur, pour permettre au système de retrouver une donnée correspondante à une clé. On peut stocker les données d’un billet avec une clé id. Mais aussi du coup, on peut par exemple affecter comme clé un offset time … pratique par exemple pour envoyer une liste avec un tel offset, ça permet de récupérer les id des billets qui n’ont pas encore été traités. On peut donc dire au système : “retrouve moi les id des billets qui ont été compostés ces trois dernières minutes !” Et après, retrouver les données des billets grâce aux ids. Redis ne sera pas utilisé tout seul. Ce sera PHP qui exécutera les commandes REDIS grâce à la bibliothèque PRedis.
- Et là. J’ai mes données dans redis. J’ai un serveur qui est sensé écouter mes compostages … Comment on peut les faire parler ces deux-là ? Comment on peut dire à ce serveur, tiens voici de nouveaux compostages ? Et là RabbitMQ est intéressant, car lui son rôle, c’est d’envoyer des messages. Je peux demander à APPS4 de livrer un message au serveur : hep toi t’as 3 nouvelles listes à écouter ! Et le serveur dépile les messages au fur et à mesure. Pas besoin que le message soit un roman … le numero de la représentation par exemple suffit … ça équivaut à un tapage sur l’épaule ;)
- Et ce fameux serveur qui reçoit mes notifications, nous le verrions bien en NodeJS … A chaque écoute il serait équipé pour gérer des pools de sockets, du genre une room par représentation. Ensuite il irait interroger Redis via une requête HTTP à chaque ouverture d’un plan pour savoir si j’ai bien le droit de me connecter dessus, du moins plus particulièrement si j’ai le droit d’accéder aux compostages de ce plan. A son ouverture, le plan envoie une requete, récupérée par NodeJS, qui va verifier la validité du token. Si c’est OK, NodeJS se connecte à la room correspondante à la rep. il serait parfait pour ensuite notifier les sockets, via un écouteur.
- Et pour les sockets, nous allons prendre socket.io, un système de sockets en JS, gérée par nodeJS, qui a de plus des modules pour gérer ce système. Donc Socket.io, il va pouvoir récupérer les données pour les envoyer au plan. Il va plus précisément envoyer, toujours via une requete HTTP, les numeros de siège qui doivent changer de couleur, rappelez-vous, mais également les données nécessaires pour les notifications. Toutes ces données seront ensuite gentiment récupérées sur le plan grâce à AngularJS qui se charge d’écouter tout gentiment. Si jamais il y a un souci avec NodeJS, par exemple une coupure … c’est lui qui va dire “hop … attention je ne reçois plus de réponse”. Il va alors laisser la main à un autre système, qui sera géré par le plan de manière autonome : un script Ajax qui écoute les sockets. Mais ce qui est bien aussi, c’est que si NodeJS remarche, ce sera également notifié et le système temps-réel reprendra le dessus ...
- Et pour les sockets, nous allons prendre socket.io, un système de sockets en JS, gérée par nodeJS, qui a de plus des modules pour gérer ce système. Donc Socket.io, il va pouvoir récupérer les données pour les envoyer au plan. Il va plus précisément envoyer, toujours via une requete HTTP, les numeros de siège qui doivent changer de couleur, rappelez-vous, mais également les données nécessaires pour les notifications. Toutes ces données seront ensuite gentiment récupérées sur le plan grâce à AngularJS qui se charge d’écouter tout gentiment. Si jamais il y a un souci avec NodeJS, par exemple une coupure … c’est lui qui va dire “hop … attention je ne reçois plus de réponse”. Il va alors laisser la main à un autre système, qui sera géré par le plan de manière autonome : un script Ajax qui écoute les sockets. Mais ce qui est bien aussi, c’est que si NodeJS remarche, ce sera également notifié et le système temps-réel reprendra le dessus ...
- AngularJS est donc le système qui gère l’affichage du plan. Il avait été choisi au départ justement pour incorporer des filtres (vendus, invendus, catégories, etc …), donc je suis restée sur ce framework. Sa mission s’il le veut bien est d’écouter ce que renvoient les sockets. Il envoie un token qui va lui permettre d’accéder aux compostages de la représentation. Comme dit plus haut, si les sockets ne répondent plus, il va chercher à se reconnecter 5 fois. Si au bout de 5 fois il n’y arrive pas … il bascule sur une boucle HTTP qui va lui permettre de récupérer les compostages qu’il n’a pas pu attrapper. Et bien entendu, ce sera lui qui se chargera de changer de couleur le siège, et d’empiler et de dépiler les notifications.
- AngularJS est donc le système qui gère l’affichage du plan. Il avait été choisi au départ justement pour incorporer des filtres (vendus, invendus, catégories, etc …), donc je suis restée sur ce framework. Sa mission s’il le veut bien est d’écouter ce que renvoient les sockets. Il envoie un token qui va lui permettre d’accéder aux compostages de la représentation. Comme dit plus haut, si les sockets ne répondent plus, il va chercher à se reconnecter 5 fois. Si au bout de 5 fois il n’y arrive pas … il bascule sur une boucle HTTP qui va lui permettre de récupérer les compostages qu’il n’a pas pu attrapper. Et bien entendu, ce sera lui qui se chargera de changer de couleur le siège, et d’empiler et de dépiler les notifications.
- Tout à l’heure je vous parlais des information que nous envoyons gentiment à Redis …
- Ce sont celles-ci. La date de compostages car elle nous permettra de créer un offset, puis elle sera également récupérée par les notifications du plan. Le code-barre du billet, le nom du bloc et le rang du siège seront également de mise pour les notifications. Le numéro de siège, lui servira pour la modification d’apparence.
- Je crée donc des valeurs ordonnées avec un ZADD et la clé repStampedSeatSet:(mon id de rep). ZREVRANGEBYSCORE permet de recupérer une liste ordonnée suivant un créneau défini avec le ZSCORE correspondant. Du coup on peut ainsi récupérer les sièges en faisant la simple requete : récupère moi les id des sièges qui ont été compostés entre 18heures 55 minutes et 30 secondes et 18 heures 56 minutes et 0 secondes … et c’est cool.
- Du coup après on peut approfondir nos requêtes. Si lors de la requête précédente, on demande gentiment : “retrouve moi tous les id de sièges compostés entre 18 heures 55 mn 30 secondes et 18h56”, on a donc une liste d’id, et on peut requeter avec ces ids pour avoir les détails. Le détail est récupéré via un HGETALL
- Alors ? Comment se passe cette récupération des compostages ?
- Le plan (AngularJS) va alors lancer une requete HTTP qui va interroger REDIS. Grace aux websockets, la récupération est lancée à chaque vague de compostages. Ensuite le plan va traiter les données. Le siège est repéré et il change d’apparence. Dans les notifications, la dernière va se dépiler, et la nouvelle s’empiler. La jauge va se mettre au diapason.
- Parlons maintenant sécurité … nous avons vu vite fait tout à l’heure qu’il y avait un token-authentification … ici il y en a un autre, qui sert uniquement à activer le compostage pour une représentation. Il sert à permettre envoyer les compostages. Il est envoyé lors du scan du billet dans APPS4.
- Donc ce token, comme c’est le cas pour tous, est stocké dans redis pour permettre sa verification. Il est crée lors du début des series de compostages, et vérifié lors de chaque envoi de compostages. Il permet d’activer le flux, grosso-modo.
- Du coup comme nous l’avons abordé, il y a ce que j’ai appelé un token-securité qui va vérifier si j’ai bien le droit de voir les sièges compostés sur mon plan.
- C’est simple : le token est crée lors du chargement du plan, et il est stocké dans Redis. Pendant ce temps, NodeJS tourne tout gentiment et il écoute l’arrivée éventuelle des tokens. Quand ça se produit, les websockets
- Voici l’exemple de code qui exprime la création du token. Nous nous trouvons sur le plan avec le code en AnglarJS. Nous voyons le listener de connection. Le script envoie une requête http qui va créer le token. NodeJS va accuser réception de l’evènement “subscribe” et traiter les résultats de la requete.
- Ici nous nous trouvons au niveau du serveur NodeJS. Il vient d’écouter l’evenement subscribe, qui rappelez-vous, a été envoyé par AngularJS. Il vérifie la validité du token avec une requete http. Si cette requete revoie true, on rejoint la room de la représentation Sinon le script s’arrete.
- Deuxième problématique : la perte de connexion. Nous pouvons avoir par exemple, une coupure du serveur NodeJS. Dans ce cas, nous ne pouvons plus recevoir les compostages.
- Dans ce cas-là, il faut pallier directement sur le plan. Il doit pouvoir gérer ces coupures de connexion lui-même. Ce qu’il fait : il écoute la perte de connexion (évènement disconnect ou connect_errors). Si il perd la connexion, il essaie 5 fois de se reconnecter. Si il n’y arrive toujours pas, il prend la main, et récupère par fréquence régulière (par exemple, toutes les 5 minutes, mais c’est configurable) les sièges qui ont été compostés. Mais il écoute toujours une potentielle reprise de connexion. Si c’est le cas, le plan arrete de chercher par lui-même et se relaisse guider par le flux : nodejs dépile d’un coup les notifications RabbitMQ déjà traitées, et re-envoie les scripts par lot de compostages.