Redis
 sql >> Base de données >  >> NoSQL >> Redis

Diffusion de messages à sécurité intégrée à consommer par un destinataire spécifique à l'aide de redis et python

Avec l'exemple et le pseudo-code que vous avez donnés, imaginons que :

  • le recipient.user1 reçoit 60 messages par minute
  • et le perform_task() méthode prend 2 secondes pour s'exécuter.

Ce qui se passera ici est évident :la latence entre l'arrivée d'un nouveau message et son traitement ne fera qu'augmenter avec le temps, s'éloignant de plus en plus du "traitement en temps réel".

system throughput = 30 messages/minute

Pour contourner ce problème, vous pouvez créer un groupe de consommateurs pour user1 . Ici, vous pourriez avoir 4 processus python distincts exécutés en parallèle avec les 4 joints dans le même groupe pour user1 . Désormais, lorsqu'un message arrive pour user1 l'un des 4 travailleurs le ramassera et perform_task() .

system throughput = 120 message/minute

Dans votre exemple, le message.acknowledge() n'existe pas réellement, car votre lecteur de flux est seul (commandes XREAD).

S'il s'agissait d'un groupe, l'accusé de réception des messages devient essentiel, c'est ainsi que redis sait que l'un des membres du groupe a effectivement traité ce message, il peut donc "passer à autre chose" (il peut oublier le fait que ce message était en attente d'accusé de réception) . Lorsque vous utilisez des groupes, il y a un peu de logique côté serveur en place pour garantir que chaque message est envoyé à l'un des travailleurs des groupes de consommateurs une fois (Commandes XGROUPREAD). Lorsque le client a terminé, il émet un accusé de réception de ce message (commandes XACK) afin que le "tampon du groupe de consommateurs" côté serveur puisse le supprimer et passer à autre chose.

Imaginez si un travailleur est mort et n'a jamais reconnu le message. Avec un groupe de consommateurs, vous pouvez surveiller cette situation (à l'aide des commandes XPENDING) et agir en conséquence, par exemple en réessayant de traiter le même message dans un autre consommateur.

Lorsque vous n'utilisez pas de groupes, le serveur Redis n'a pas besoin de "passer à autre chose", l'"accusé de réception" devient 100 % côté client/logique métier.