0
votes

Quand Redis Pub / Sub Événements est-il incendié et oublier?

Redis Events sont le feu et l'oublie. Si personne n'écoute, ils resteront simplement détectés. Il n'y a pas d'histoire. Mais nulle part sur Internet n'a-t-je trouvé quelque chose qui répond à la question suivante (j'utilise Redis-Py et AIOREDIS pour Python):

Le code doit-il réellement écouter les événements pour le recevoir ou le cache de connexion ReDIS Événements pour moi?

Supposons que j'ai cette boucle: xxx

permettra de manquer tous les événements qui se produisent dans le calcul des 5s ou mon redis_db les cache pour moi?

En d'autres termes ... Feu - et-oublie s'applique si je n'ai pas une connexion ou si j'ai Une connexion, mais je suis ne pas écouter ?


0 commentaires

3 Réponses :


2
votes

Comme vous l'avez mentionné, si vous utilisez Redis Pub / Sub, c'est un incendie et oubliez donc votre application doit être opérationnelle et d'écouter l'événement.

Je dois dire que je n'ai pas testé votre cas d'utilisation.

Pour votre logique, d'avoir plus de contrôle, je vous suggère de regarder Redis Streams .

  • Tout d'abord, ce n'est pas une publication de pompiers et d'embouchons. S'abonner, UT un système de messagerie plus résilient.
  • Votre application contrôlera les messages à lire, doivent être lus et envoyer un ACK lors de la lecture.

    Votre pseudo-code sera très facile à mettre en œuvre avec des flux, avec un meilleur contrôle.


1 commentaires

Bonjour, merci pour vos efforts pour écrire cette réponse. Eh bien, mon exemple de base était juste pour une explication. En réalité, seriez-vous si gentil et répondez également à une question plus précise que je vous ai posée il y a un moment? Cela m'aiderait vraiment à commencer à commencer avec Redis Streams: Stackoverflow.com/questions/60248078 . Merci beaucoup. +1



0
votes

"Feu et oublie" s'applique au contrat du serveur avec le client. Cela signifie que le message ne sera envoyé qu'une seule fois, en supposant que le client est connecté. Si le message est perdu dans le réseau et que je ne reçois jamais au client, c'est ça. Si le message atteint le client et le processus client / serveur se bloque avant de le lire, c'est ça.

Dans votre cas, le client (ReDIS-PY) écoute sur la prise réseau qui facilite la connexion au serveur. La prise elle-même est gérée par le système d'exploitation et tamponnez les messages entrants. Tant que vous continuez à drainer la prise en lisant de ses messages ne sont pas perdus.


0 commentaires

1
votes

C'est un peu des deux. Vous avez besoin d'une connexion et que la connexion doit être dans un état "abonnement". Dès que l'exécution de la méthode "blocking_subscribe", vous avez modifié efficacement les connexions d'état à l'état "Souscription" afin que REDIS continuera de tamponner ces messages pour vous, si votre thread Python est occupé à traiter d'autres messages en même temps. Maintenant, bien sûr, s'il s'écrase pour une raison quelconque, alors ce tampon latéral du serveur de Connexions sera perdu.


2 commentaires

Salut. Merci pour votre réponse claire. Avez-vous réellement essayé, est-ce quelque part dans les docs où je ne l'ai pas vu, ou est-ce plus une hypothèse?


C'est juste comment Redis fonctionne. Pour plus de détails, il est expliqué ici: Redis.io/topics/clients