Dans le domaine des systèmes distribués, le mécanisme de type Pub/Sub permet de découpler les producteurs de données des consommateurs. Le système de stockage central agit comme un point de relayage. Lorsque le stockeur contient des informations pertinentes pour un abonné spécifique, celui-ci est automatiquement notifié et peut traiter la donnée à sa réception. En l'absence de nouvelles entrées, le processus de consommation reste bloqué jusqu'à ce qu'un événement se produise.

Cependant, selon l'implémentation du serveur, le comportement face à une saturation de la mémoire varie : certains blocquent l'émission tandis que d'autres abandonnent les paquets excédentaires. Dans l'architecture Redis, contrairement aux middleware comme Kafka qui utilisent des Topics, les flux sont organisés autour de chaînes (Channels).

Principales commandes de manipulation

• Adhésion à une chaîne (SUSBCRIBE) : Permet à une session client de s'intéresser à une ou plusieurs chaînes nommées explicitement. Une fois la commande lancée, le terminal se place en écoute passive tant que la désinscription n'est pas demandée.
• Adhésion par expression régulière (PSUBSCRIBE) : Fonctionne sur le principe du wildcard. L'utilisation du caractère générique (*) permet de cibler tous les canaux correspondant à une préfixe donné, offrant ainsi une flexibilité accrue pour la surveillance de groupes de sujets.
• Émission de notification (PUBLISH) : Injecte un payload texte au sein d'une chaîne identifiée. La réponse du serveur indique le nombre total de clients actifs ayant reçu cette information, permettant de valider la diffusion.
• Gestion de la sortie (UNSUBSCRIBE / PUNSUBSCRIBE) : Ces instructions libèrent la connexion des écoutilles précédemment définies. Appelées sans arguement, elles ont pour effet de rompre toutes les connexions actives établies via leurs contreparties respectives (SUBSCRIBE ou PSUBSCRIBE).

Outils d'inspection interne

L'instruction PUBSUB sert à interroger l'état actuel du service de messagerie. Elle accepte trois sous-commandes distinctes :

• CHANNELS [motif] : Répertorie les chaînes possédant au moins un auditeur actif. Le filtrage par motif est disponible via le wildcard.
• NUMSUB [chaines...] : Donne le décompte précis des abonnés pour chaque chaîne spécifiée.
• NUMPAT : Retourne l'agrégat total des modèles d'écoute configurés par tous les clients connectés.

Mécanisme de transaction Redis

Contrairement aux bases de données relationnelles classiques, le traitement par lots chez Redis ne garantit pas l'ensemble des propriétés ACID. Il assure principalement l'exécution séquentielle et atomique d'un groupe d'instructions, mais sans capacité de retour arrière global (rollback) en cas d'erreur partielie. La persistance des résultats dépend des stratégies RDB ou AOF, indépendamment du contexte transactionnel. L'isolation repose sur un verrouillage optimiste géré via des observations de clés.

Workflow opérationnel

Le cycle de vie d'une séquence transactionnelle implique quatre directives majeures :

1. MULTI : Démarre la phase d'accumulation. Les ordres suivants sont mis en file d'attente sans exécution immédiate.
2. EXEC : Procède à l'exécution physique de la file. Si une clé surveillée a été modifiée extérieurement entretemps, toute l'opération est annulée et retourne vide.
3. DISCARD : Interrompt la préparation actuelle et purge la file d'attente sans impact sur la base de données.
4. WATCH : Place un observateur sur une ou plusieurs clés avant de lancer le batch.

Exemples concrets d'exécution

Suivez ci-dessous des scénarios illustrant le fonctionnement du batching et du contrôle d'accès concurrentiel.

# Scénario 1 : Exécution standard d'un lot
redis> MULTI
OK
redis> DECR stock_article_a
QUEUED
redis> DECR stock_article_a
QUEUED
redis> SET statut_stock "modifie"
QUEUED
redis> EXEC
1) (integer) 98
2) (integer) 97
3) OK

# Scénario 2 : Validation via verrouillage optimiste
# On surveille le compteur global avant modification
redis> WATCH index_global
OK
redis> MULTI
OK
redis> INCR index_global
QUEUED
redis> SET dernier_update "active"
QUEUED
redis> EXEC
1) (integer) 505
2) OK

# Scénario 3 : Échec dû à une modification externe
# Clé lock_res surveillée pendant la configuration
redis> WATCH lock_res tentatives_ecritures
OK
redis> MULTI
OK
redis> SET owner_data "serveur_principal"
QUEUED
# Intervention tierce ici : changement de tentatives_ecritures
redis> EXEC                  # Retourne nil car la condition initiale a changé
(nil)

Notez que l'instruction UNWATCH permet de lever manuellement la surveillance si elle n'a pas été suivie par une exécution ou un abandon, bien que ces deux actions la réinitialisent implicitement.