Fonctionnement Receive & Delete: Le message est marqué "delivré" dès que le lecteur demande le message, charge à lui de ne pas le perdre
Si l'appli plante avant d'avoir traité le message, celui-ci est perdu
at least once (au moins 1 mais peut etre plus):
Fonctionnement Peek Lock:
1) Le message est marqué "lock" dès qu'un lecteur demande un message
2) Le lecteur traite le message de son côté
3) Le lecteur marque le message "consumed" lorsqu'il a terminé
Le message peut être marqué "abandoned" par le lecteur afin de signaler à SB qu'il est de nouveau disponible à la lecture pour les autres
Un timeout associé au message remet le message en disponibilité si le lecteur ne l'a pas marqué "consumed" dans le temps imparti
Si l'application demande un nouveau message à SB avant d'avoir marqué le précédent "consumed" alors SB redonne le message qui à priori vient d'être traité (d'où le "au moins 1")
exactly once:
Fonctionnement en Peek Lock
L'activation de la feature Duplicate Detection permet à SB de ne pas redélivrer un message à un lecteur qui l'aurait déjà eu mais qui n'aurait pas eu le temps de marquer le message "consumed" (par ex. à cause d'un crash)
Le Producer rompt la communication avec le Topic immédiatement après avoir envoyé le message (par ex: il plante)
Lorsqu'il établit de nouveau la communication, il faut un moyen pour le Producer de détecter que le dernier message qu'il a traité a bien été envoyé au Topic et ce même s'il n'a pas pu le marquer comme tel autrement le message va être envoyé une seconde fois dans le Topic pouvant causer des problèmes de cohérence de données
Permet à la queue ou au topic de supprimer automatiquement les doublons de message arrivant des Producer
La dédup s'appuie sur le MessageId du message pour le conserver ou le drop
Le MessageId doit être défini du côté applicatif
Si Partitionning activé:
L'identifiant du message correspond au MessageId+PartitionKey
Si Message Session est également activé, le SessionId doit être identique au PartitionKey
Configuration de la durée de l'historique des messages pour détecter un doublon:
Un lot de messages formant un flow de transaction est envoyé vers une queue/souscription
Ceux-ci arrivent parmis d'autres messages qui n'ont rien à voir avec ce flow
Pour un Reader, il faut un moyen de lire les messages qui sont liés à ce flow uniquement et ne pas être "pollué" par des messages qui n'ont rien à voir avec ce flow
Géré au niveau applicatif en définissant le sessionID (group-id en AMQP) dans les messages qui constituent la session
Lorsque SB détecte la propriété il fonctionne en mode "session"
Les producers continuent d'envoyer des messages aux topics, chacun avec leurs numéros de sessions
Lorsqu'un reader lit une session (= Accept session):
Il possède un lock exclusif sur tous les messages avec le même sessionID dans la queue/souscription
Le lock s'applique également aux messages qui arriveront dans la queue/souscription
Le reader peut ainsi lire l'ensemble des messages d'une session et ce peu importe s'ils ne sont pas arrivés d'un bloc dedans (= s'ils sont entrelacés avec d'autres messages qui n'ont rien à voir avec cette session)
Le lock est relâché par appel de close() du reader ou bien lorsque le TTL du lock expire
1 seul lock possible par session (= 1 seul reader par session)
Session State:
Le reader peut stocker des données de contextes d'une session directement au niveau de SB pour cette session
Méthodes SetState et GetState
Doit être géré au niveau applicatif Reader, le reader y met ce qu'il veut dans cet espace
Il faut clean le session state lorsque la session est terminée autrement l'espace de stockage continue d'être consommé
réplication 3-active sur 3 availability zone de la région Azure , ce qui devrait assurer un haut niveau d’uptime (le SLA du service est à 99.9%).
Attention toutefois: le SDK intègre déjà une logique de retry s’il perçoit un problème de connexion au endpoint, ce qui signifie que l’application qui utilise l’API REST doit implémenter sa propre logique
Le cas qui non couvert est celui d’un regional failure:
il faut s’appuyer d’une part sur la feature Geo Disaster Recovery du tier Premium afin de répliquer la configuration de l’instance du service vers une autre instance SB dans une autre région
d’autre part prévoir une réplication des messages (voir lien n°3) pour assurer le RPO qui convient, ce qui pose des contraintes de gestion des doublons/acquittements de messages répliqués en plus de poser des contraintes de performances (l’article n°3 propose différents pattern d’implémentation en fonction des cas à gérer).