Forum général.cherche-logiciel Réagir à des données expirées (date) en DB

Posté par (page perso) . Licence CC by-sa.
Tags : aucun
0
14
nov.
2016

Bonjour,
je recherche une solution afin de réagir à des données expirées en db:

  • un site web propulsé par Django
  • postgresql en base de données
  • les sessions seront stockées dans un Redis (important)
  • un serveur websocket

Ceci n'est pas figé mais:
- je dispose du serveur websocket (un serveur asynchrone en rust, code perso forké de ws-rs)
- Sessions stockées par Redis car le serveur websocket à besoin de savoir qui est connecté au site pour accepter ou pas le handshake websocket.

Un utilisateur pourra ajouter un événement depuis le site.
Celui-ci aura une 'date' (dans le futur) de fin de validité.
Cet événement sera donc stocké dans un champ pg.

A 'date_event - delay' (delay sera configurable par l'utilisateur pour chaque événement), je dois prévenir l'utilisateur (message websocket) que son événement est sur le point d'expirer.
A 'date_event', je dois prévenir l'utilisateur (message websocket) que son événement a expiré et je dois supprimer cet événement de la liste des événements disponibles des autres utilisateurs du site (message websocket pour chacun des utilisateurs connectés et concernés par cet événement).

Ayant des choses à faire en db avant l'envoi des messages websockets, les callbacks de ces expirations devront passer par django.

Postgresql ne peux pas m'aider à résoudre cette situation (pas de cron interne donc pas de trigger possible et je ne souhaite pas écrire d'extend pg).
Je pense qu'une solution basée sur le cron du système ne soit pas envisageable (une tâche se réveillant toutes les x secondes et scannant la table pg adéquate entraînera trop de charge inutile en fonction du nombre d'enregistrements).

Une solution possible serait d'utiliser Redis: EXPIRE et KEYSPACE NOTIFICATIONS. Mais si j'ai bien compris, je dois disposer d'un client connecter à un Pub/Sub channel pour recevoir les notifications.

La solution que j'envisage est de partir comme un gros bourrin sur l'écriture d'un service rust.
Je commence à bien maîtriser mio-rs qui dispose d'un système de timer:
- à chaque ajout d'un événement utilisateur, django passe les infos adéquates au daemon rust qui configure les 2 timers.
- à l'expiration d'un des timers, le daemon rust en informe django qui pourra manipuler l'événement en db et enverra les messages adéquates aux utilisateurs en passant par le serveur websocket.

Avez-vous déjà été confronté à ce genre de situation (callbacks à l'expiration de champ en db) ?
Quelles autres solutions peuvent être envisagées ?


  • # celery + rabbitmq

    Posté par (page perso) . Évalué à 5.

    A la creation de ton événement, tu ajoutes une tache dans rabbitmq qui devra s'exécuter à la date d'expiration.

    Ca marche bien, c'est fait pour ça, et celery/rabbitmq s'intègre très bien dans django.

    J'ai mis en place ces technos pour envoi/expiration automatique de notifications.

    • [^] # Re: celery + rabbitmq

      Posté par (page perso) . Évalué à 1.

      Merci,
      cette solution me semble robuste, s'intégrera bien avec le reste de mon écosystème
      et non bloquante en cas de recherche de haute disponibilité.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.