Videos

language: FR

                  WEBVTT
Il y a des gens qui ont déjà installé et qui n'arrivent juste pas à se connecter à
l'interface d'admin.
Pourtant le port est par défaut le bon, un 5, 6, 7, 2.
Et la première suspicion qu'on a c'est est-ce que ce n'est pas un truc de firewall,
est-ce que les ports sont bien ouverts, etc.
Alors je vais vous mettre tout de suite sur la bonne voie.
Ce n'est pas ça.
C'est que cette interface de management, c'est un plugin aussi.
C'est-à-dire que là pour l'instant vous avez installé RabbitMQ avec quelques plugins
de base, mais les plugins ça s'active et ça se désactive.
Donc je vous laisse farfouiller dans la documentation sur comment vous pouvez administrer la liste
des plugins.                

on 2024-03-13

language: NN

                  WEBVTT
噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi
je vais aller regarder par là
Philippe est d'accord bien sûr c'est pour plus jeune
je reste que vous avez des questions
est-ce que tout le monde a pu envoyer un message vers une QO et faire un binding au moins ?
噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi
噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi
噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi
噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi
噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi
噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi
噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi
噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi
噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi
噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi
噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi
噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi
噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi
噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi
噫 ke l'un de vous veut se lancer et nous montrer expliquer un peu son archi                

on 2024-03-13

language: FR

                  WEBVTT
Est-ce que tout le monde a pu envoyer un message vers une Qo et faire un binding ?
Allez allez, encourageux, quelqu'un vient nous montrer.
Vous voulez que je commence ?
Sur mon écran partagé, je vais mettre ce que je vois.
C'est une très bonne question à poser dont on n'a pas du tout discuté.
Est-ce qu'on veut aussi spliter les messages ?
Qu'est-ce que tu as mis sur ton exchange ?
Je voyais aussi que sur tes QoS, tu avais mis le single active consumer.
Les petits tags bleus qu'on voit, le SAC, c'est l'option au moment de créer la QoS
de single active consumer qui a mis un trou.
Il ne peut y avoir qu'un seul client connecté à la fois.
Cela permet d'éviter des soucis de charge trop importantes.
Tu limites puisque l'utilisation choisie chaque voiture va avoir sa propre Qo.
Autant mettre des restrictions pour ne pas être emmerdé au niveau réseau.
S'il y a des bugs, c'est le système qui nous empêchera de faire des bêtises.
Le SAC sert à ça.
Plutôt comme un garde-fou.
C'est cool.
Quelqu'un d'autre a fait différent et veut nous montrer ?
Vas-y.
Ouais.
Typiquement, il faut que tu recrées un exchange.
Oui.
C'est un des trucs qui fait râler les gens régulièrement dans les forums.
Les gens disent comment ça, je ne peux pas modifier les autres.
Après, une fois que c'est en place, c'est en place.
Ta seule solution, c'est de le détruire et recréer.
Si tu as fait un lien...
Je vais exprès répondre à ta question en disant que ça dépend.
Si tu as un lien vachement fort entre les QoS et les exchanges,
dès que tu touches un truc côté exchange,
tu es emmerdé au niveau Q
et potentiellement tu vas devoir refaire une nouvelle Q
et bouger les messages.
C'est possible aussi que tu aies un truc relativement découplé
au niveau de la logique
et que redéfinir l'exchange,
le détruire et le recréer,
ne t'oblige pas à changer quoi que ce soit
au niveau des Q et des messages existants.
Ça dépendra un peu du cas.
Mais oui, s'il y a besoin potentiellement de bouger une Q...
La réponse est la même si c'est une Q que tu veux modifier.
Modifier les options.
Là, il faut que tu fasses quelque chose des messages qui sont dedans.
On verra des exemples demain de manipulations concrètes
de merde, on a trois messages,
il faut qu'on utilise une nouvelle Q maintenant.
Qu'est-ce qu'on fait de ces trois messages ?
On va avoir des solutions pratiques.
Pourquoi on ne peut pas modifier ?
La réponse sort un peu du cadre de la formation.
Je pense que c'est un peu comme toutes ces technologies
où les objets que tu crées,
les exchanges, les Q, tout ça,
ils ont un fonctionnement au bas niveau
qui est vachement dépendant des options que tu as mises.
Si tu veux changer une option,
c'est pas du tout un truc au niveau virtuel
que maintenant il va fonctionner plutôt comme ci que comme ça.
Quand tu as mis l'option à la création,
il a choisi une structure particulière pour fonctionner.
Ce qui fait que si tu veux changer,
tu dois recréer un qui va potentiellement avoir une forme différente.
C'est ça, tout à fait.
Modifier des options de configuration,
c'est potentiellement un chantier de migration
et non pas juste un flag qu'on active ou pas en lançant une commande.
Non, tu ne peux pas.
Maintenant, encore une fois,
la réponse est non.
Encore une fois,
sur un exemple comme celui que vient de nous montrer Mathieu,
où on choisit pour notre implémentation
que c'est le client qui a besoin de consommer des messages
qui définit la queue au moment où il se connecte.
Il dit que si elle existe, tant mieux,
mais si elle n'existe pas, crée-la.
On s'attend à ce que ce soit toujours le deuxième cas.
C'est-à-dire qu'on va faire en sorte que la queue disparaisse
si le client se déconnecte.
Tu vois, un truc dans le style.
Du coup, cette question du renommage de la queue
pose moins de soucis,
puisque la responsabilité de la nommer, même de la créer,
elle est au dernier moment
et la responsabilité est côté client.
Par exemple, la question est moins emmerdante que dans d'autres cas.
Mais oui, effectivement, tu as tout à fait raison de dire
qu'il faut se poser des questions avant d'aller en prod.
Si tu configures quelque chose et que tu pars en prod
sans avoir fait des tests de scénarios différents,
est-ce que tous mes scénarios sont couverts
et que j'ai de la flexibilité et de la performance dans un deuxième temps ?
Oui, tu vas avoir des soucis.
Est-ce que quelqu'un d'autre veut montrer ce qu'il a fait spécialement ?
J'ai fait quelque chose d'assez proche de Mathieu.
J'ai fait un exchange que j'ai appelé Traffic Update.
Moi, j'ai mis deux types Topic,
mais il se trouve que pour l'instant, je n'ai même pas mis de binding encore.
Vous allez voir.
Il est bindé à rien du tout.
Donc je n'ai même pas fini le boulot.
Par contre, j'ai fait même Philosophie.
J'ai décidé que j'avais une queue par client
et que je leur mette des noms comme ça, comme Mathieu,
des noms variables.
Je vais appeler ça.
J'ai mis des points.
Update.car.inidentifiant.
Qu'est-ce que j'ai mis ?
Je n'ai pas choisi le timeToLive comme tu nous as montré.
J'ai fait l'autre méthode dont on a parlé dans la discussion.
C'était de dire que je vais faire en sorte,
je vais en ouvrir une des deux,
elles ont la même config, les deux qui s'appellent Car.
Update.car.
Et puis ça, ce serait la partie variable entre guillemets
de mes noms de queue.
Alors, je leur ai mis une longueur maximum de 3.
C'est-à-dire...
Ah non, je dis une bêtise.
Il y en a une C3, l'autre C5.
Donc, déjà, elles n'ont pas la même.
Donc, trois messages maximum ou cinq.
Ce qui veut dire que je ne vais pas m'embêter
à garder plus de messages que ça.
Et tout va se faire automatiquement.
Même si les messages arrivent plus lentement
que ce à quoi je m'attends,
comme je n'ai pas mis de time to leave,
ils vont rester jusqu'à ce qu'ils disparaissent.
Et le overflow ici,
la propriété overflow,
c'est pour le fonctionnement attendu
quand il y a trop de messages,
quand le quatrième message ici va se présenter.
Donc, drophead, c'est celui qui est le plus en avant
dans la file, va être dégagé
pour que tous puissent s'empiler plus loin.
Voilà.
Le plus ancien disparaît.
Singer Active Consumer,
Mathieu l'avait mis aussi,
puisque comme on a dit, c'est un bon garde-fou
si c'est le mode d'utilisation attendu.
Et puis, qu'est-ce que j'ai mis d'autre ?
Ah oui, j'en avais fait une au début.
Alors, je vais vous remontrer dans cette interface-là.
J'en avais fait une, comme ça,
qui s'appelait updates.car.
Je ne sais pas, on va mettre un identifiant quelconque.
Et je l'avais mis alors,
max length,
donc voilà, 5 messages, on va dire,
overflow behavior drophead,
très bien.
Single Active Consumer,
allez, comme ça,
on s'évite des problèmes.
Et puis, j'avais mis auto-expire.
Auto-expire, ça fait quoi ?
Je vous le rappelle, ça fait que
s'il n'y a pas de client qui se connecte à cette queue,
elle disparaît au bout d'un moment.
Ce serait pas mal, ça, en fait, comme option dans notre système,
parce qu'on va se retrouver
dans la recette de queue, là,
avec une queue par client.
Imaginez, il y a 1000 voitures qui se connectent,
on va avoir 10 000 queues,
qui ont chacune très peu de messages.
On aimerait bien que
non seulement les messages
disparaissent automatiquement,
je pourrais même combiner les deux,
je pourrais même mettre max length et message TTL,
si je voulais être agressif
sur mon effacement de messages,
pourquoi pas.
Le max length, dans ce cas-là,
il éviterait que trop de messages s'empilent,
et que mes queues deviennent trop longues.
Et le TTL ferait en sorte
qu'il n'y ait pas trop de données persistées
qui servent à rien, parce qu'au bout de 2 heures,
on peut considérer que je m'en fous, en fait.
Je pourrais combiner les deux.
Mais en plus de ça, je ne veux même pas garder les queues,
s'il n'y a personne qui les lit.
Et là, dans ce cas-là,
ce serait tout à fait justifié de mettre un auto-expire.
Et on peut considérer que
c'est une queue par client.
Peut-être qu'il va se déconnecter
parce qu'il passe dans un tunnel, je ne sais quoi.
On va lui laisser quelques minutes, peut-être,
pour se reconnecter, éventuellement.
Et au moment où il se reconnecte,
il va dire, j'aimerais lire sur cette queue
et créer là si elle n'existe pas.
Sauf qu'il s'est reconnecté et elle existe encore,
elle n'a pas expiré.
Donc là, on voudrait peut-être lui laisser un temps,
une chance, je ne sais pas,
on peut mettre 10 secondes ou 30 minutes
mais là, c'est un peu au choix.
On va mettre une heure.
3600 x 1000.
Si après une heure, il ne s'est toujours pas reconnecté,
on dégage
la queue pour ne pas nous encombrer.
Donc notre système va se nettoyer tout seul.
Et puis voilà ce que je disais.
Je ne l'avais pas fait mais je peux aussi mettre un TTL.
Par exemple, 10 minutes.
10 minutes, ça va faire 60 000, c'est ça ?
60 000, c'est ça ?
Non, 600,
je vais trop de mal.
1 minute 60,
600 000.
Voilà, donc tu vois,
avec un système comme ça,
tu es tranquille
parce que ça va se nettoyer tout seul.
Tu ne vas pas voir grand chose
mais rien n'empêcherait
deux clients.
Tu ne verrais pas de différence
sauf que ça permettrait
à deux clients de se connecter
sur cette même queue.
Concrètement, toi, pour ton système,
ça ne changera pas grand chose.
Ça peut être emmerdant sur
un autre scénario
où
il y a un risque
qu'il y ait des milliers de clients
qui se connectent sur la même queue
et que ça fasse un engorgement à ce niveau.
Là,
on pourrait imaginer une situation comme ça.
D'ailleurs, ce sera l'exercice suivant.
Là,
on pourrait être embêté.
Mais dans le cas ici,
concrètement, si je ne le mets pas,
si je mets d'ailleurs, regarde,
on va mettre à false,
tu vas voir, il ne va même pas mettre
si flag dans les features.
Il ajoute.
Tu vois, ma carte ici,
celle que je viens de créer,
elle a TTL,
elle expire,
elle a donc aussi limit et overflow,
mais elle n'a pas SAC,
puisque j'ai mis false suite à ta question.
Sauf que là, maintenant, cette queue
qui n'a pas de clients,
expire,
donc là, j'ai mis une heure,
donc on ne va pas voir, mais tout à l'heure,
quand je l'ai fait, j'ai mis une minute.
Et après une minute, elle a disparu,
la queue, puisqu'aucun client
ne s'est jamais connecté.
Et donc, la queue, vu les règles
que j'ai mis ici,
elle a appliqué la règle,
qui est « ça fait le temps que tu m'as dit
que je n'ai pas de connexion,
je m'effrace ».
Ok ?
Donc avec un système comme ça,
tu peux faire du nettoyage.
Et bien sûr, vous avez compris,
il faut discuter avec les devs,
notamment tous ces délais, par exemple.
Je vais vous montrer autre chose.
Et puis je n'ai même pas fait les bindings encore.
Alors j'en ai fait une quatrième ici,
que j'ai appelée « Update app »
Android, etc.
C'est juste pour discuter,
c'est très abstrait encore,
mais ce serait l'idée que,
maintenant que mon système fonctionne,
pourquoi ne pas permettre aussi
de faire une application mobile
qui recevrait des notifs aussi.
Sauf que là, par exemple,
ça m'intéresserait de pouvoir voir
l'évolution du trafic
en remontant un petit peu en arrière,
donc de devoir faire une sorte de truc
de replay pour voir si ça a changé.
Et donc ce que j'ai fait ici,
c'est que j'ai dit que celle-là
pouvait avoir jusqu'à 20 messages.
Et puis j'ai mis un TTL sur les messages,
je ne sais même pas pourquoi.
Mais l'idée, c'est que ici,
par rapport aux autres,
j'avais besoin que du dernier message
sur un GPS de voiture.
Le dernier message, c'est tout, ça suffit.
Donc j'ai mis 3, 5,
comme le maximum.
Là, je mets 20 parce que peut-être
sur l'application, je veux faire une espèce de replay
avec les 20 derniers messages.
Ici, il y en a 20.
Et puis,
j'ai fait ça un peu vite,
j'ai même pas mis de
overflow behavior ici.
Donc on ne sait pas ce qui se passe
quand il y a trop de messages.
Alors justement, ça c'est une bonne question.
On va tout de suite aller voir dans la doc.
Il y a les modes de fonctionnement,
c'est soit, quand la queue est pleine,
quand tu mets maxlink,
un nouveau message qui se présente
va pousser tout, et donc le plus vieux,
le premier dans l'air.
Et puis,
ça c'est drophead.
Et l'autre mode de fonctionnement,
c'est que
le nouveau message qui se présente
ne peut pas rentrer parce que la queue est pleine.
Et puis là, t'as encore deux options.
C'est-à-dire que ce nouveau message
qui ne peut pas rentrer,
il va soit être dropé, tout simplement,
il ne va pas rentrer dans sa queue.
Alors attention, c'est juste par ce binding.
Peut-être que le message,
avec d'autres bindings,
il va quand même arriver au bout,
par ce binding-là, sur cette queue,
il ne rentre pas et il est dropé.
Deuxième option,
il n'arrive pas à rentrer,
et il part dans
les fameux dead letters,
c'est-à-dire les messages
qui n'ont pas réussi à être routés,
ils vont dans un exchange spécial.
Ouais.
Ouais, c'est ça.
C'est ça.
Voilà, c'est ça.
Et,
un autre truc
que je voulais vous montrer aussi
sur les queues,
est-ce qu'on va le voir ici ?
Tu me remontes trop.
On va le voir,
il n'a peut-être pas.
C'est bizarre, j'ai fait sur Fac.
Je pensais que j'en avais fait autrement.
Donc,
pour continuer la discussion
toujours sur cet exemple-là,
on peut imaginer de faire
updates car identifiant,
ou puis
de déclarer la queue comme
transient. Alors, qu'est-ce que c'est, ça ?
Vous vous souvenez,
c'est, est-ce que ça survit au restart ?
Posons-nous la question.
Imaginons, on a 500 bagnoles connectées
à notre système, chacune regarde
sa queue, et puis,
le serveur crasse.
Bon, bah, a priori,
côté GPS, il va dire
« Ah, j'ai perdu la connexion ».
Donc,
au moment où ça va restarter ici,
enfin, côté broca,
est-ce que c'est
vraiment pertinent de restaurer ces queues
qui correspondent
factuellement
à une queue
qui correspond à une connexion active
d'un client
qui
a atterri sur ce
node-là, quoi,
auquel il a demandé de créer
la queue pour lire les messages.
Donc,
si à un moment donné la connexion est érompue,
a priori,
on peut établir comme principe
dans notre contrat
avec les développeurs que le GPS,
oui, il va essayer de se reconnecter, bien sûr.
Mais du coup, il va potentiellement
se reconnecter
à un autre node
dans le cluster,
et donc recréer une queue là-bas.
Ce qui veut dire que quand notre node qui a craché va restarter,
on peut se débarrasser de toutes les queues
sans problème,
puisqu'elles correspondent à une connexion active.
Et que même si
par hasard,
le GPS
se reconnecte à nous,
on peut tolérer
de devoir recréer la queue et
mettre des nominates, etc.
Donc c'est une discussion,
à voir si on peut se permettre de perdre toutes les queues.
Plutôt oui, comme ça.
Après, on peut imaginer un système
où il n'y a pas de cluster, il n'y a que ce serveur-là.
Et du coup,
s'il y a une connexion qui pète entre
la voiture et le node,
on pourrait
dire, ouais, ok, allez, on va restaurer les queues
comme ça, les messages sont encore dedans,
et puis celui qui se connecte,
il retrouve ses messages,
et bon, ça sera un cas particulier.
J'irais que dans...
si je devais faire une architecture comme ça,
et qu'on se mettait en cluster,
et que le GPS, la voiture, il se connecte à
n'importe quel node disponible
à tout moment,
j'ai envie de dire, autant faire du ménage,
et donc on met toutes les queues
en transient.
Il n'y a pas besoin de survivants en Vista.
Vous voyez, c'est des trucs super bas niveau,
des petites configs qui changent
le fonctionnement à un niveau presque
hardware, en tout cas,
système.
Mais en fait, c'est des questions métiers
à se poser.
Moi, c'est pour ça que je trouve
très très intéressant cette technologie
de broker de messages.
Mais c'est...
il faut que les devs et les amis
communiquent bien.
Alors, Leader Locator, j'en ai toujours pas parlé,
on verra demain, c'est un truc lié
au cluster.
Est-ce que, sur toutes les
options qui étaient disponibles pour les queues,
vous avez eu
des questions,
expérimenté des trucs
qui n'ont pas marché. On verra les deadletters
très très bientôt dans la
formation.
Mais là, on a utilisé pour l'instant, vous voyez,
auto-expire,
message-ttl, overflow-behaviour,
max-length,
single-active-consumer,
et puis max-length
bytes, on l'a pas encore utilisé.
C'est l'équivalent de
max-length, mais plutôt pour une taille
en fait.
La place que prennent,
le code de message.
Je crois
que c'est tout. Alors, je vous avais dit
j'ai pas encore fait les...
j'ai pas encore fait
les bindings.
Un téléphone qui s'est fait...
Donc là, bon, je pourrais m'amuser,
mais je pense que vous avez compris.
Si j'ai bien compris tout, on va réussir
à faire passer un message.
Donc là, vers mon topic, je pourrais maintenant
faire...
Donc toi, t'as fait des directs ?
Moi, je pourrais mettre, par exemple,
ici, avec mon topic.
Allez, je vais le faire.
Est-ce que je peux faire ça ?
New tab.
Oui.
Est-ce que je peux faire ça ? Ça va marcher, là ?
Pas trop.
Non, c'est pas mal.
Allez, ça ira très bien.
Donc, ce que je voudrais maintenant, c'est
faire un seul binding.
Pardon, une seule clé de routage.
Tu vois,
je vais dire que j'envoie ça
updates.car.
Il faut que je copie le nom ici.
Je trouvais qu'ils auraient pu faire un petit effort
et nous mettre des listes déroulantes.
UGCVU, par exemple.
Mais comme moi, j'ai pris un topic,
je peux faire un truc de style
traffic.cars.
Donc, c'est une update
de type traffic.
Tu vois, ma clé de routage,
elle peut être...
Ça n'a pas forcément grand-chose à voir
avec le nom de l'exchange ou le nom de la queue.
Je ne vais pas mettre traffic, en fait.
Je vais mettre...
Info route.car.
On va mettre en français.
Info route.car.
Et je vais mettre ici,
par exemple,
ce qui veut dire que maintenant,
je peux...
Alors attends,
je ne dis pas de bêtises.
Info route.car.
On va faire comme ça.
On va faire...
On va faire 3.
J'aimais bien la question
qui a été posée sur
la question de la position géographique.
Donc,
par cette queue, on va mettre
info route.car.
Point...
sud-ouest.
Et puis, par exemple,
info route.
On va mettre même... Regarde.
Étoile.car.sud-ouest.
Alors, c'est quoi, ça ?
Donc, maintenant,
là, ce que j'ai fait, c'est que je reçois
toutes les mises à jour
qui concernent les voitures.
Mais tu vois, j'ai pas mis ici
de...
de dièse.
Parce que je ne veux pas recevoir
toutes les news de toutes les régions.
Moi, je viens de m'abonner à la région sud-ouest.
Donc, c'est le client, potentiellement,
de cette voiture-là
et qui a dit
créer cette queue, d'accord ?
Et puis, c'est probablement
le client qui a créé ces bindings-là.
Parce que lui, il sait qu'il est dans la région sud-ouest.
Et donc, il a dit, ben voilà,
je m'abonne, entre guillemets,
aux news du sud-ouest.
Donc, comment je fais ça ?
Je fais un binding entre l'exchange
traffic update
et puis ma queue.
Et donc, je vais l'appeler
inforoute.carz.sud-ouest.
Comme ça, toutes les infos
qui concernent le sud-ouest, je vais les recevoir.
Ensuite, peut-être que je vais avoir
des messages qui vont concerner
toutes les voitures de toutes les régions
de nos pays.
Et à ce moment-là, la clé de routage
de ces messages, ça va être inforoute.carz.
C'est-à-dire, je veux prévenir toutes les voitures.
Par exemple, ça va être
la vie de tempête sur la France,
faites attention, risque de verglage,
on ne sait rien, quelle que soit la région.
Et tu veux l'envoyer à tout le monde, tout le monde.
Donc, je m'abonne aussi à ça.
Par contre, s'il y a un message qui est routé
avec inforoute.carz.régionparisienne,
ben là, je vais pas le recevoir, du coup.
Tu as l'idée ?
Et puis, la clé de routage
du haut, là, c'est quoi ?
C'est étoile.carz.sud-ouest.
C'est tout ce qui va être des informations
qui sont à destination
des automobilistes dans le sud-ouest,
mais qui ne sont pas,
qui ne concernent pas le trafic,
qui peuvent être, par exemple, je ne sais pas,
des pubs, d'autres infos.
Potentiellement, je vais pouvoir
en fait aussi les recevoir.
Je ne sais pas quelle va être leur nature.
C'est au moment de recevoir le message
que je verrai la clé de routage
et que je déciderai si oui ou non, c'est pertinent pour moi.
Mais en faisant un binding comme ça,
maintenant, le système, il a la possibilité
de m'envoyer des choses qui sont
d'autres news, tu vois,
qu'infos.route.
Vous voyez, on peut créer de la complexité,
en fait. Là, on ne gratte que
la surface
de ce qui est possible.
Et puis, bien sûr,
on peut aussi s'amuser
à faire un exchange.
Alors, tu vois, il y avait une autre
stratégie, par exemple.
Là, j'ai mis « Traffic Update ».
On pourrait imaginer un truc compliqué.
On essaiera de le faire demain.
On va avoir un premier exchange
qui est « Traffic Update ».
Et puis, en fonction de paramètres
qui sont dans
le message
qui va rediriger vers certains
exchanges, par exemple
Sud-Ouest, région parisienne, etc.
Donc, des exchanges, voilà, comme ça.
« Traffic Update »,
Sud-Ouest, par exemple.
Et qui, lui, serait de type
« Fan-out ».
C'est-à-dire qu'on ne va même pas s'embêter
avec du routage. Et moi, ma voiture,
elle vient,
elle se connecte, elle dit « Je veux cette queue-là
et je voudrais m'abonner à
« Traffic Update » Sud-Ouest.
Et je n'ai pas besoin de mettre une clé de routage.
Je vais recevoir tout ce qui arrive
dans ce exchange-là.
Et puis, je veux aussi m'abonner, peut-être,
à « Traffic Update » pour d'autres trucs.
Tu vois, tu peux t'abonner,
depuis une queue, tu peux t'abonner à plusieurs exchanges
ou bien plusieurs bains.
Voilà, l'exemple, on pourrait en faire,
on pourrait faire deux jours juste là-dessus.
On va s'arrêter là.
Est-ce que...
Donc, on reviendra, on réutilisera cet exemple-là
pour faire des trucs plus complexes.
Mais est-ce que vous avez des questions ?
Sinon, on va passer à l'autre.
On va essayer d'aller en...
Oui, vas-y, vas-y, non, non.
Tu vois, on essaie quand même, c'est vrai,
depuis le début, de définir des scénarios
qui seraient plausibles et tout.
Après, par exemple, en prod,
ce serait assez rare que...
Donc, tout dépend.
Dans un système comme ça, en général,
des mises à jour d'infotrafics,
elles vont être fournies par...
un fournisseur qui nous donne ses infos.
C'est vraiment comme une agence de news
qui nous envoie les dates.
Et maintenant, il faut qu'on définisse, en fait, ici,
qui nous sommes là-dedans.
Est-ce que nous, on est, par exemple, le fabricant du GPS ?
Auquel cas,
nous, on cause directement
avec les voitures,
avec les machines qui sont embarquées chez nos clients.
Si on est TomTom, tu vois, ou je ne sais quoi, là.
Si c'est nous, nos clients, effectivement,
c'est directement les voitures.
Si on est plutôt côté
diffusion de cette information,
type une agence
du style API
qui fournit des data payantes
à d'autres
prestataires informatiques qui, derrière,
en font quelque chose pour le client final,
nous, effectivement, ceux qui vont venir se connecter chez nous,
ce n'est pas les voitures directement,
il va y avoir potentiellement quelqu'un,
une autre entreprise d'informatique,
justement TomTom,
qui va se connecter chez nous,
récupérer un max d'infos
et puis les pousser vers ses clients.
Selon qu'on est TomTom,
ou qu'on est celui qui fournit les data
à des TomTom et ses concurrents,
on ne va pas se poser du tout les mêmes questions,
parce que dans un cas, par exemple, TomTom,
ça peut être pertinent de dire
« ouais, pas de problème, on va créer une queue
par voiture
et puis on va gérer
ce qu'on vient de faire, là, en fait.
On va gérer vraiment au niveau de notre logique
un dispatching des messages dans RabbitMQ,
qui va avoir pour
préoccupation combien de temps
restent connectés les clients, les déconnexions possibles,
c'est grosso modo ce qu'on vient de faire,
on a duré des messages,
tout ça, tout ça, tout ça.
Si on se place dans la position de
nous, on est broker d'informations,
broker au sens
agence, quoi,
on diffuse ces informations-là
pour TomTom, pour Google Maps,
on fournit les infos à d'autres,
nos préoccupations
sont plus du tout les mêmes, parce que là on a beaucoup moins
de connexions potentielles.
On a par contre, peut-être, des gens
qui veulent conserver une copie
des données
chez eux, en cache,
assez longtemps, parce que voilà,
on est découplé et ils veulent, eux, avoir l'historique
au cas où, tu vois.
Donc, on va peut-être leur mettre à disposition
les choses beaucoup plus longtemps,
mais les autoriser à rester connectés,
peut-être qu'on va faire des queues
qui ont des noms préétablis
et c'est nous qui allons
maintenir ces queues, c'est pas eux qui vont les créer
au moment où ils se connectent, on va se mettre d'accord
avec eux, ils nous payent
un million à l'année et nous,
on maintient les queues pour eux, quoi, tu vois.
Pareil,
on verra les questions de clusterisation
demain. Donc, la clusterisation,
en gros, c'est
la répartition de charges
de ce qu'on trouve en aval,
c'est-à-dire les queues et les messages,
et il y a une
virtualisation dans le cluster de ce qu'il y a
en amont, les exchanges, en fait, tu vas les retrouver
dans tous les noms
et c'est après
le cluster qui va savoir où
acheminer le message, concrètement.
Mais,
voilà, pareil, selon le
scénario 1 ou 2,
tu vas
avoir, quand il y a un besoin plus ou moins fort
de répartir
des data.
Donc, ouais, tout
dépend, mais si on était sur le scénario, voilà,
nous, on est top top, je pense que ce qu'on a fait,
c'est pas trop mal, en fait, et c'est réaliste,
une queue par
TGPS, là.
Un truc intermédiaire, ce serait,
tu as un serveur
par
région,
alors, région, c'est pas obligé
d'être tout le sud-ouest, ça peut être
plus petit, peu importe. On va dire
les quatre gants de région française,
plus la région parisienne.
Dans ces
cinq serveurs, signes eux
reçoivent des messages
et là, tu vas faire du
routing en fonction de
si le message est pertinent ou pas.
Et puis, toutes les
voitures vont s'abonner
à ce serveur-là
et à la même queue
qui va être
les objets. C'est possible aussi.
Et donc là, tu partirais sur une architecture
complètement différente. C'est dur de dire
s'il y en a une qui est mieux qu'une autre,
il faudrait vraiment
aller plus loin encore dans la précision
du problème pour faire
des tests et puis se dire
en fait, ça, ça va pas.
Mon exemple, tu vois,
on ne citait que un, mon exemple
de, tiens, si la voiture va dans un
tunnel,
et puis, il n'a plus de connexion,
est-ce que c'est important
que quand elle se reconnecte,
enfin, déjà, comment elle va se reconnecter ?
Est-ce qu'elle va
forcément tomber sur la même instance ou pas ?
Et puis, quelle est la durée
que je peux tolérer ?
D'avoir une queue
qui n'a pas de client ?
Tu vois, avec ça,
c'est tout un, tout un truc
que je ne sais pas parce que ce n'est pas du tout mon métier,
en fait.
Alors, il est quelle heure ?
15h47 ?
Est-ce que vous avez besoin
d'une pause ? Criez, si c'est le cas.
Ça va ?
Vous pouvez faire une pause maintenant jusqu'à 16h, si vous le souhaitez.
Ou bien, je vous montre encore
des trucs et puis on fait une pause vers 16h, 16h40,
un truc comme ça.
Attends, on va utiliser des features
de notes, ça marche ce truc ?
Ouais, non, ça, c'est ma main.
Comment je fais un vote ?
Bon, je ne vais pas faire un vote dans le chat.
C'est pas grave.
On peut faire ça dans le team ?
Ok, c'est pas grave.
Ok, je vous propose un truc.
Je vous montre le problème suivant.
On ne va pas passer autant
de temps sur les quatre.
Une fois qu'on a fait un, je pense qu'on a compris
un peu les principes.
Je vais vous montrer qu'on peut se poser d'autres questions.
Donc, on va parler
des trois suivants.
Et puis on prend un petit break.
Donc, le deuxième scénario
news type AFP par sujet,
c'est
on est une agence
de presse
qui diffuse des
brevres
avec liens, etc.
C'est des objets riches.
Il y a potentiellement
peut-être même des liens vers des photos.
Il diffuse des brevres
avec liens,
images, etc.
Pour des professionnels.
Donc, accès
immédiat
sans limitation
de volume, etc.
On a compris que c'est des accès payants.
Mais aussi
le grand public
selon des termes
différents.
Voilà.
Donc,
et
là, l'idée,
c'est de dire
les news sont
les news sont
réparties
selon des
thématiques
dont la liste
fixe et connue
avance.
Des tags,
si vous préférez.
On peut dire que des tags, peu importe.
Et pour ajouter
un peu,
une news peut être
tagguée
dans plusieurs
thématiques. Pourquoi pas.
Voilà.
Vous voyez, problème complètement différent
puisque maintenant,
est-ce que
ici, par exemple,
c'est plus important que dans l'exemple
précédent avec l'infotrafic.
Ici, c'est un peu plus
de conséquences de perdre un message.
C'est pas la fin du monde.
On n'est pas sur du truc
de centrales nucléaires
ou d'informations
historiques de transactions financières
où là, c'est catastrophique.
Mais c'est emmerdant quand même
de perdre un message.
Comparé à l'autre, on a la foi
si on en perd un, c'est pas grave,
il y en a un qui arrive juste après
et ce qui compte, c'est le dernier.
Donc, voilà.
Vous voyez, c'est pas noir ou blanc.
C'est pas catastrophique, mais c'est emmerdant.
Et puis voilà,
les réponses aux questions
sont différentes. Est-il important de garder
les messages longtemps ? Plutôt oui
parce que
c'est pareil, c'est pas mon métier.
Je vais un peu bosser d'ailleurs avec la FP
il y a très longtemps, mais c'est pas mon métier.
Et c'est vrai qu'ici,
ça peut être pertinent de pouvoir
remonter dans le temps de
même plusieurs semaines pour voir
quelles étaient
les news
sur un sujet
la semaine passée,
il y a un mois, etc.
Alors peut-être que
justement, c'est une question à poser
aux développeurs ou aux chefs de projet
on peut
marquer
certaines news
comme importantes
doivent rester
consultables
longtemps
et d'autres
comme plus volatiles
disparaissent au bout d'un moment.
Vous voyez, on peut
même avoir
des messages qui vont pas avoir
le même valeur
entre guillemets
et on va les persister
on va les laisser disponibles plus longtemps
dans certains cas.
Pareil, la question
est-ce qu'un client qui consomme un message
doit le laisser dispo pour les autres ?
Alors là, oui, plutôt.
Bien sûr, on peut partir sur une architecture
comme avec nos voitures, là,
où chacun va créer sa petite queue, etc.
Mais comme ça
intuitivement
on a envie de se dire
que ça ne paraît pas optimal
dans la mesure où on va vachement
copier de l'information
potentiellement
sur un grand volume
si on est sur le grand public.
Alors, si on rentre vraiment dans les détails
en vrai, le grand public
ce serait certainement un site web
que nous on est à disposition
et qui s'alimente sur notre système
via une queue
par thématique.
Je spoil un peu la solution qui serait de mettre
une queue par thématique.
Donc c'est pas le grand public qui va venir
sur les queues directement, parce qu'il y aura
certainement un site web qui va les afficher.
Bon, on est...
C'est pas forcément
la multiplication des nombre de queues qui est inquiétant ici.
C'est plutôt
le fait que
si un client
consomme
un message
et ça disparaît
ça nous oblige à faire ce système
où chaque client doit avoir sa queue, etc.
Peut-être que
ce serait plus
pertinent, dans ce cas là
de faire
une queue
où tout le monde peut venir se servir.
Et on peut même
imaginer
un système hybride
où on aurait...
oublions pour l'instant le portail client
une seconde
et puis on va juste regarder nos
contacts B2B
les professionnels.
On pourrait même imaginer que selon le plan
qui paye, s'il paye
le plan bas de gamme ou le plan haut de gamme
au niveau de tarification
on va leur donner une queue dédiée
dans le cas où il paye cher
ou bien ils vont se servir là où
tout le monde vient
dans le cas où il paye pas cher.
Et du coup là c'est un petit peu la foire d'empoigne
parce que s'ils sont trop à se connecter
potentiellement ils ont des soucis, etc.
C'est pas aussi performant que si on leur met
leur queue pour eux à disposition.
Et tout ça, ça peut être dans le même cluster
avec
des configs différentes.
Et en fait c'est exactement les mêmes messages
qu'on va balancer
dans toutes ces queues à la fin qui vont être dupliquées.
Et vous voyez on peut imaginer
des trucs complexes.
Et donc voilà, j'ai un peu spoilé
l'idée qui serait de dire
là on va plutôt séparer
les queues par sujets.
Alors pourquoi ?
C'est un choix comme un autre.
On pourrait mettre toutes les braises à la suite et laisser les gens trier.
Mais
il y a des chances que
vu le métier
certains
des clients
de browse en fait
ne récupèrent des messages que dans certaines
thématiques qui les intéressent.
Imaginons on a une chaîne de sport
dans nos clients et puis on a une chaîne
politique et puis on a une chaîne
je sais pas
d'autres
thématiques.
Ils vont pas consommer les mêmes
infos et donc ça va
de facto
nous faciliter vachement
le travail d'optimisation
pour les performances de tout ça
de répartir
par thématique
au niveau de nos queues. Parce qu'on va tout de suite
pouvoir
voir plus clair
en gros les problèmes
seront plus facilement identifiables.
On peut très dire ça.
Si on a
40 chaînes de sport comme clients
et qu'ils sont sur une queue
tous et qu'on a régulièrement
des problèmes sur cette queue là
bon
on peut tout à fait
imaginer si on a pas de problème sur les queues
politiques
on va se dire ok
ils sont trop nombreux et il va falloir que
on fasse plus de queues qu'on répartisse
qu'on fasse en sorte
qu'ils tapent sur 3 nodes
ou 5 ou 7
ou 8
Qu'est-ce que je vais encore dire ?
Cet exemple, non, Monsieur Jopama
Ah oui, il y a l'histoire des messages
volatiles
ça peut même s'implémenter
avec les options de base
c'est à dire que, bien sûr
on peut construire des architectures plus complexes
on va avoir des archivives
qui sont consultables ailleurs
mais nous, au niveau de
si on fait des queues par exemple, qui peuvent contenir beaucoup
de messages, je ne sais pas
un millier par exemple
ça peut aller à plusieurs millions
sans problème, mais imaginons on va garder
1000, 2000 messages
et on va quand même mettre une limite
on va pouvoir mettre
à chacun de ces messages
une durée de vie différente
directement dans le message en fait
cette fonctionnalité ici là
elle est implémentable
on peut dire au développeur, il n'y a rien à faire
tu utilises une option de RabbitMQ de base
et tu as cette feature
déjà disponible
les messages vont s'empiler
et puis régulièrement
il y en a qui vont en fait disparaître
tout seul et ça va
tout va se réordonner
au fur et à mesure
donc on va avoir les vieux messages
qui doivent rester, qui sont toujours là
et puis il y a des messages qui sont les plus récents
qui s'accumulent, mais certains disparaissent, certains restent
on va pas le faire concrètement
comme manique, on s'arrête à la discussion
est-ce que vous voulez parler encore un peu plus de celui-là ?
alors réception de commandes e-commerce
alors là c'est un exemple
où
on va dire
on est qui ?
la centrale
qui contient
tous
les articles
à expédier
un entrepôt
en fait tout dépend de comment
il est organisé l'entreprise, mais
un entrepôt
c'est du dropshipping
un site partenaire
envoie
une commande de son client
donc il y a trois parties
moi, le site
son client
ici la centrale qui contient tous les articles à expédier
c'est il n'y a que deux parties
moi, le client
et où est-ce qu'on est ?
le bureau
il n'y a toujours que deux parties
c'est moi et le client
qui envoie des ordres
de livraison
vers le bon entrepôt
rien que sur cette question là
il faudrait préciser dans quel scénario on est
soit ce sont des exemples réels
soit ce sont des exemples réels
il y a des e-commerce
où c'est assez simple
l'entreprise c'est aussi l'entrepôt
et puis le site
les articles disponibles sur le site
c'est tout ce qu'il y a dans l'entrepôt
c'est un business spécialisé
j'en ai vu des gens qui ne vendent pas
des cosmétiques naturelles
ils ont leurs propres matériels
articles pardon
leurs propres stocks
il y a des matelas aussi
l'entreprise elle fait que l'e-commerce
elle reçoit les commandes
du site
elle doit les traiter et derrière elle va dispatcher
vers un entrepôt
peut-être qu'il y a des entrepôts
qu'elle gère elle-même
et peut-être qu'il y a des entrepôts partenaires
qui ne sont pas à partir de l'entreprise
mais qui peuvent
livrer l'article
ça c'est le mode hybride
le troisième mode le dropshipping pure
c'est à dire que moi en tant qu'entreprise
je n'ai aucun entrepôt
je ne fais que
alors pardon
je suis encore sur le bureau
je reçois les commandes c'est mon site
mais moi je n'ai aucun entrepôt
je ne contacte que
des entrepôts tiers
et puis le troisième
c'est le point de vue de l'entrepôt
lui-même en fait
il n'a pas de site
il ne reçoit que des commandes
à envoyer quelque part
c'est ce qu'on appelle le dropshipping
il y a un gars quelque part qui a fait un site
il reçoit des commandes dessus
il les envoie vers l'entrepôt
et l'entrepôt envoie donc ça fait un triangle
donc là
on pourrait en parler longtemps
de tous ces scénarios
mais les questions intéressantes
c'est toujours une même
est-ce que c'est grave de perdre un message ici ?
c'est vraiment problématique de perdre un message
parce que, alors il n'y aura peut-être pas Mordome
c'est toujours pas la centrale du éclair
mais
il y a potentiellement un client
qui a payé et qui ne reçoit pas son article
donc c'est forcément
des emmerdes
donc ici, perdre un message
c'est embêtant
ici c'est
très problématique
exemple, le client a déjà payé
qu'est-ce qu'on a d'autre ?
est-ce que c'est important ici
de garder les messages longtemps ?
en fait la question ici
elle se pose pas tellement
parce qu'on n'est pas sur de la diffusion d'informations
on est sur un processus métier
donc là ici notre broker
il ne sert pas
à pousser
de l'info que les gens vont consommer
quand ils ont envie
c'est totalement différent
ici chaque message
est en fait
une étape critique
d'un processus métier
bien défini
et donc la question
de garder les messages longtemps ou pas
quelque part elle est presque pas
pertinente
il faut que les messages soient traités
après ils peuvent être rejetés
genre
t'as vendu un article qui n'est pas en stock
donc il n'est plus disponible
on peut très bien traiter
en disant je rejette ça
mais à ce moment là on va
traiter le message et faire ce qu'il faut
dans ce cas là
mais on est toujours dans le processus métier
si vous voulez
on peut pas se permettre de ne pas traiter le message
donc la réponse à combien de temps
faut garder les messages
donc si potentiellement
côté entrepôt
on a une panne informatique de 2 semaines
il faut que tous les messages
restent en attente
et puis on va envoyer des excuses aux clients
pardon on a eu un problème informatique
mais ne vous inquiétez pas
toutes les commandes seront honorées
on gardera tous les messages
et puis est-ce qu'un client qui consomme un message
doit le laisser disponible pour les autres
ben là
c'est pas forcément une question très pertinente
ici puisque
on va exécuter
évidemment que chaque commande une seule fois
donc si on est sur
on a fait une architecture informatique très compliquée
où il y a plein de
clients
qui se connectent à notre middleware
c'est sûr que si
il y en a un qui traite le message
il faut pas que les autres le traitent
aussi
on risque sinon d'envoyer
deux fois un article à quelqu'un qui ne l'a pas fait une fois
donc là
la question pareille
elle est un peu mal posée dans ce cas là
parce qu'on s'en fout
de laisser disponible un message pour les autres
c'est plutôt non
la réponse
mais c'est surtout un problème
d'architecture à définir pour respecter le processus
donc oui
le middleware finalement il permet
de faire plein de choses différentes
et dans certains cas
certaines des features vont être disponibles
déjà dès les options de base
comme on a vu tout à l'heure
pour les news
qu'heure il est 16h06
et dernier cas
peut-être que celui-là on le fera aussi
si on a le temps
un manip
c'est
on peut imaginer
un système
où
plutôt que
donc imaginons
un système où
des utilisateurs
peuvent ajouter
un appareil
du style
appeler bancaire
autoriser un téléphone
je ne sais rien
et on voudrait faire un système
qui identifie
l'appareil
ça peut être aussi de l'authentification
j'aime bien pareil
ou bien même
s'authentifier par exemple
rapidement
autoriser un browser
etc. vous avez compris
on peut imaginer
un système qui serait basé
entièrement sur RabbitMQ
avec des
queues et des
des exchanges
astucieusement fabriqués
donc certains à la volée
d'autres qui sont là en permanence
et puis
on va gérer aussi
on va utiliser les time to leave
les durées d'expiration des messages
et tout pour
on veut des time out
question de sécurité
on va utiliser les options
de TTL, expiration, tout ça
pour si
le processus
d'ajouter l'appareil
aux appareils auxquels on fait confiance
et pourquoi pas
ne vient pas au bout
dans un temps imparti
que on soit obligé de recommencer
du début
vu que le système est
faillible
on va laisser une fenêtre limitée
dans le temps pour que les gens puissent s'en servir
on veut des time out par exemple
et on veut
un truc
simple à utiliser
du genre code à 6 chiffres
donc
c'est vraiment
type
authentification de factor
to factor
authentication
ou ce qu'on appelle les magic links
tous ces systèmes là
qui permettent de
belpasser les authentifications
plus traditionnelles de user password
je ne parle pas du tout de token
là je parle vraiment de ces systèmes
qui permettent de rendre
une connexion entre
deux choses faciles pour l'utilisateur
c'est ça vraiment la clé ici
ce qu'on désire
j'ai implémenté par exemple un système comme ça
pour permettre à
des utilisateurs sur un portail web
d'ajouter des
machines
ces machines
c'est des ordinateurs
mais qui
ont la capacité de se connecter
au middleware
ce qu'on voulait c'était dans le portail web
pouvoir ajouter la machine
pour ensuite pouvoir
faire des trucs avec depuis le portail web
envoyer des messages vers cette machine
voir son statut
gérer des conflits éventuellement
mais donc ce qu'on a besoin si vous voulez
c'est d'infos sur la machine
comment communiquer avec elle
vraiment du type IP etc
mais on n'a pas envie de
s'embêter on n'a pas envie de demander à l'utilisateur
rentre
dans un formulaire et tape toutes les infos
sur la machine ce qu'on veut c'est plutôt
dire sur la machine appuyer sur un gros bouton
qui dit register this device
et puis dans notre portail web on appuie sur
un gros bouton qui soit register
a new device
et puis que la machine nous donne un code à 6 chiffres
et que dans le portail web on tape les 6 chiffres
et puis
qu'on récupère les infos de la machine
dans le portail
et de ça en fait on a implémenté en pure RabbitMQ
avec un petit peu de code
quand même
un moment donné
il y a un petit peu de logique
à implémenter
c'est plus un défi de programmeur
mais l'essentiel
de la tuyauterie c'est fait avec RabbitMQ
et des options de base
donc je vous montrerai comment on peut implémenter ça
avant la fin
de la formation
et puis si on a le temps on essaie pas de le faire
mais voilà
donc ça peut vraiment servir à faire plein de trucs différents
c'était le but
de cette phase
de manip et de discussion
alors
vu qu'il est 16h11
on s'approche de la fin
on n'est même pas obligé de faire un break
on suit juste une demi heure
de cours
ce qu'on peut faire
c'est qu'on va finir un petit peu plus tôt
tout simplement
sauf si vraiment vous êtes en train de mourir
vous voulez qu'on s'arrête 5 minutes
vous me dites
ça va ?
ouais je vous ai pas trop assomé
ça joue
là on a créé
nos instances de rabbit
on a des machines virtuelles
on va se resservir de tout ça demain
pour attaquer la partie clusterisation
et justement
cette fois on parlera
d'abord de considération
plus système
et puis on reviendra après
aux questions plus métier
pour voir l'impact sur tout ce qu'on a vu
une fois qu'on met en cluster
où vont les messages
et pour finir aujourd'hui
simplement je vous proposais
de nous parler des problèmes
que vous avez rencontrés
par exemple ce que je sais pour l'instant
c'est uniquement que sur vos instances de dev
ça tombe en carafe de temps en temps
et vous suspectez un problème de mémoire
mais si je m'en souviens vous êtes même pas sûr
mais voilà
je vous propose d'ouvrir la discussion
pour parler de ça
et comme ça on sera un peu aussi préparé demain
à l'arrivée des dev
début d'après-marche c'est ça tu as dit Serge ?
début d'après-marche
est-ce que
alors je sais pas
c'est qui
Thierry et
Mathieu
qui ont dû
maintenir un peu les
instances en dev j'ai bien entendu
on parlait d'autre chose Mathieu et Thierry
ouais bah vous vous dites voilà on te dit
je prendrais quelques notes
je note peut-être en même temps
moi je vois ouais c'est bon
donc ça, ça veut dire que
ouais ça fait
en fait
les messages sont pas
je pense c'est des bindings simples
du coup tu dois pas mettre non plus
de clés de routage j'imagine dans les messages
et puis tu balances
donc tu fais l'équivalent
d'un fan out
c'est à dire
bah
ça j'ai pas encore la réponse à cette question
parce que j'ai envie de dire
la techno elle est quand même faite pour ça
c'est ça qui est voulu au niveau de la distribution
encore une fois
ça dépend de ce qu'essaient de faire les gens
en revanche c'est vrai que si
vous utilisez pas les clés de routage à ce moment là
autant utiliser un fan out
parce que le fan out va même pas
comparer les clés
donc au niveau perf on va gagner un peu
quoi
mais c'est la seule chose que j'ai à dire pour l'instant
de ce que je veux
c'est dur de dire
c'est plus une question
à discuter
en regardant l'architecture et le
besoin de tir
vous avez
tiré des nouveaux nœuds c'est ça
et vous avez pris les messages
vous avez balancé sur l'autre nœud
d'accord
ok
effectivement
on voit que
il n'y a pas de 9800 connexions
mais que 29 channels
donc en fait pour faire quelque chose
un client
qui se connecte
il va établir une connexion
et il va forcément créer un channel
on a toujours un
par défaut minimum
même si on
fait pas plusieurs channels dans la connexion
pour faire des choses
de façon élégante et tout ça
de toute façon il y a toujours un channel
c'est à dire que si tu veux vraiment savoir combien il y a de gens connectés
tu vas plutôt regarder les channels
que les connexions
là ça va te dire
il y a potentiellement
30 connexions
vraiment actives
qui font quelque chose
et puis 9800
60
qui en fait
peuvent refaire parce qu'ils n'ont pas de channel
c'est sûr que là il y en a beaucoup qui
continuent
alors
alors c'est
de ce que je vois
c'est vrai que c'est plutôt
côté client en général
les connexions qui
restent ouvertes en fait
parce que voilà
l'architecture fait que
c'est possible
ah oui
oui c'est ça et donc mais je veux dire
le client lui il n'a pas
les connexions sont pas ouvertes côté client tu dis c'est ça ?
ouais c'est ça on pourra peut-être
rejeter un œil à ça demain
on va s'armer le matin
de connaissances
sur le fonctionnement interne
le cluster
oui bien sûr
bien sûr ouais ouais
je suis content parce que moi dans toutes les formations
j'essaye de faire du cli et
les gens aiment pas le cli classé le contraire
c'est cool
tu dis ça s'appelle MQTD
connector
explorer d'accord
ok
ouais tout à fait
mais c'est en ligne de commande d'accord ?
ok d'accord
on fera pas mal de
on va montrer différentes solutions
effectivement mais
je trouverai aussi de vous donner des scripts
pour faire ces fonctionnalités de base
mais on peut faire pas mal de choses
en ligne de commande aussi
ok merci
le mec il revient sur les taux
le mec il joue aux échecs pendant l'information
et il revient
merci
ouais c'est vrai
très très bien
écoutez
je regarde encore si
au niveau slide je voulais vous montrer autre chose
aujourd'hui
mais vous n'êtes pas mal là
donc
on a vu les headers
c'est assez important
on va parler des
ouais
elles sont pas bien ces slides
on va parler du reroutage
des messages en cas d'erreur
demain
mais ça va être vraiment
la notion métier pour l'instant
élémentaire qui nous manque encore
petit mur qu'on construit là c'est la brique
c'est toute la partie
attends je suis où là
oui je partage plus vite
ah bah non évidemment c'est pas bon j'arrive
je vais juste vous montrer dans l'interface où ça se trouve
et puis ça va faire base de l'info
c'est ça
ok
donc
dans mon système
avec exchange
binding et queue
je vais en fait avoir à différents niveaux
on pourrait même mettre une slide pour montrer les différents niveaux
qu'ils soient pas trop moches si possible
j'aime pas celle là en fait
voilà c'est ça que je cherchais
donc
si l'exchange arrive au niveau de l'exchange
si l'exchange arrive pas à le router ce message
premier cas où on veut pouvoir
traiter ça comme une erreur
et dire bah envoie le message du coup ailleurs
c'est à dire c'est vraiment le
ce matin on a parlé de poubelle
c'est pas tout à fait une poubelle
ça peut faire partie même
de votre processus métier bien sûr
ça sera aussi les erreurs
qu'ont fait les développeurs
cette année les développeurs
quand ils nous envoient un message bien sûr
mais ça peut aussi faire partie du processus normal
de dire bah voilà si je n'arrive pas
à router le message avec les bindings existants
envoie le là parce que peut-être que
c'est tel autre cas
dans le processus métier
vous voyez c'est
on peut avoir ça comme une poubelle trop vite
donc au niveau ici de l'exchange
déjà on a des mécanismes
et puis ensuite au niveau de la queue
on va avoir des mécanismes
en lecture
donc au moment où le client va se connecter
pour lire un message il va pouvoir dire
hey ce message là
non seulement
je le récupère pas
il m'intéresse pas
mais en plus je te signale
qu'il y a un problème avec ce message là
et le client va nous dire
problème avec ce message
donc c'est ce qu'on va appeler un reject
on revira tout ça concrètement
je vous rassure
on verra des exemples
mais le reject va être un deuxième cas
comme ça
où un message
dans notre système va
potentiellement devoir aller
ailleurs
dans le middleware
donc
pas adressage
foiré au niveau de l'exchange
rejet au niveau de la lecture
et puis les cas
typiques par exemple
un message
il y a une taille limite dans la queue
et le message
qu'on veut pousser
dans cette queue peut pas rentrer
parce qu'on a dit
que tu sais on a pas choisi
FIFO là où le premier il dégage
on a dit quand la queue est pleine personne peut rentrer
et donc le message qui va se présenter
en sortie de l'exchange
et à l'entrée de la queue
il va pas pouvoir y aller
bien que l'adressage soit correct
troisième cas
où le message va pouvoir se retrouver
dans les circuits
qu'on avait prévu pour ces cas là
donc on verra tout ça demain il y a encore d'autres cas
il n'y a pas que ces trois là
mais c'est des exemples pour vous dire que
on va pouvoir ajouter comme ça de la logique
et puis selon le cas
ça va faire complètement partie du processus métier
où c'est plutôt vous
qui allez discrètement
entre guillemets sans dire aux devs
faire votre truc de votre côté
pour dire bon ok
quand leur processus là il y a des trucs qui vont pas
moi je récupère les choses en fait
et je garde l'info sur ce qu'il y a à foire
et donc c'est encore une fois
quelque chose qui peut se faire
en modélisant le métier
ou plutôt en mode système
donc on verra des exemples
voilà
dans l'interface
ça va se retrouver là
quand on définit ici
un nouvel exchange
voilà c'est parti
tout est prêt
il y a un petit parlement à l'interface
parce que là je replie l'exchange
et on garde la liste pour ce moment
donc add new exchange ici
quand je vais définir un exchange
je vous disais s'il a un problème d'adressage
ou est-ce qu'il peut l'envoyer
ça va être justement l'option qu'on a ignoré tout à l'heure
alternate exchange
qui nous dit
if messages to this exchange cannot be routed
on remarquera l'accent français
send them to the alternate exchange
maintain
donc ça va être
son alter ego
si vous voulez
si lui il a pas réussi à envoyer
le message ou que ce soit
donc ça c'est optionnel
au niveau des queues
on a ici
dead letter exchange
si un message expire
donc si le message
il est dans la queue
il disparaît
ou qu'il est rejeté par le client
donc je vous disais
le client il dit
il récupère le message
il dit ouais celui là
je vais
je te signale que je le rejette
et bah
dead letter exchange c'est pareil
on va donner comme option ici dans cette queue
un nom d'exchange
et ça va fonctionner comme le alternate
sauf que cette fois ci c'est au niveau de la queue
alternate c'est au niveau de l'exchange
donc ça s'appelle dead letter
le petit acronyme c'est
dlx dead letter exchange
et puis dead letter routing key
c'est une option supplémentaire
dans ce cas là pour je vous l'avais dit ce matin vite fait
pour réécrire la clé de routage
dans les cas
où on l'envoie par le dlx
ok ?
et voilà
donc c'est une brève introduction
à ce que
on verra demain
mais comme ça en disant ça maintenant
j'ai brossé un tableau à peu près complet
de l'utilisation
de RabbitMQ
là vous pouvez déjà vous lancer dans un petit projet
avec ces connaissances
et bien sûr
nous pendant les jours qui nous restent
on va approfondir
voilà, vu qu'on n'a pas fait de pause
cet après-midi
on peut dire qu'on est bon
si vous avez des questions je vous écoute
et sinon
merci
et à demain, je vais rester connecté jusqu'à 17
quand même au cas où le mec il veut
manipuler et qui boit des trucs
c'est bon
pour l'enjeu                

on 2024-03-13

language: FR

                  WEBVTT
Alors IP, je vous avoue, je ne me suis pas embêté parce qu'il y a l'IP interne sur
leur réseau.
Alors du coup, moi je crois que ça marche aussi normalement.
Mais je fais whatismyip.com et j'ai utilisé celle-là et ça pique aussi.
Si on prend celle interne à leur réseau, normalement ils doivent se voir, mais on                

on 2024-03-13