Très bonne explication de victor.
Pour info, un "broker" c’est ce qu’on appellerait en Français un courtier.
Si on prend le parallèle avec la finance, voilà ce que dit Wikipedia :
Par son action, il sert d’intermédiaire pour une opération, le plus souvent financière, entre deux parties.
Tu lui envoies des ordres, il s’occupe de les propager aux gens que ça intéresse, il sert d’intermédiaire.
Dans le cas qui nous intéresse ici, on parle de message broker.
L’intérêt d’un tel système c’est de permettre de faire du publish/subscribe. C’est-à-dire que tu as un ensemble de publishers (ceux qui produisent de la donnée, comme les capteurs dont parle victor) et un ensemble de subscribers (des consommateurs qui vont recevoir la donnée, la traiter, la stocker, ou que sais-je encore).
Quand tu as un publisher pour un consumer, c’est du "point à point". Il te suffit de connaître l’adresse de destination et tu l’envoies. Il existe des tas de système pour faire ça depuis que l’informatique existe :
-
remote procedure call
-
webservice
-
API
Là, c’est simple.
Mais ça montre vite ses limites :
-
si le consommateur ne répond pas lorsqu’on lui envoie la donnée, qu’est-ce-qu’on fait ? Je la stocke chez moi et je renvoie plus tard ? Quand ?
-
si le consommateur n’est pas capable d’absorber les données au rythme auquel je les envoie ? Là on peut faire rentrer en jeu ce qu’on appelle des mécaniques de back-pressure. Exemple : j’envoie qu’un message sur 4, ça suffira
-
si mon consommateur décide de changer d’adresse, de mode de réception, etc., je dois tout ré-implémenter
-
et évidemment, si je n’ai plus un, mais plusieurs consommateurs, il faut leur envoyer à chacun chaque message (et du coup, gérer le cas où ils ne répondraient pas, etc.)
Bref, ça devient très vite complexe.
Un broker, ça sert à simplifier tout ça pour les deux parties.
D’un côté, le producteur se contente d’envoyer les messages au broker, en les identifiant comme il faut "ça c’est un message de type ’température’, c’est en degrés celsius, ça vaut 26, ça a été relevé à 17h30, à Paris". Son job s’arrête là.
De l’autre, les consommateurs vont simplement s’abonner à un sujet en particulier auprès du broker. Genre "moi ce qui m’intéresse, c’est les températures, pas la qualité de l’air, je m’en fiche". Ils vont venir "poller" (interroger, dans le jargon Kafka) le broker à intervalles réguliers pour savoir s’il y a de nouveaux messages.
Il peut y avoir plusieurs consommateurs abonnés à un même sujet. Il peut même y avoir plusieurs instances d’un même consommateur (bah oui, si t’as énormément de messages par seconde, il va te falloir un paquet de consommateurs pour absorber les messages à un rythme correct). Dans ce cas, c’est le broker qui va garder la trace de "pas besoin de t’envoyer cette température, ton copain d’a côté l’a déjà récupéré tout à l’heure" (tout à l’heure == il y a quelques millisecondes)
Charge au consommateur de transformer le message si besoin, etc. Un fois que le broker lui a donné le message, il ne s’occupe plus de rien.
On voit bien que la partie spécifique de l’implémentation est aux deux bouts de la chaîne, déléguée au producteur et au consommateur.
Entre les deux, on a une mécanique assez complexe (réplication, historisation, distribution, etc.) mais qui reste tout à fait générique.
D’où l’intérêt d’utiliser un système conçu pour.
