0
J'ai une exigence où je pousse mes clés à redis avec un certain temps d'expiration. Avoir également un abonné pour écouter les événements d'expiration de la clé, puis avoir un rappel à mon autre système qui peut effectuer certaines règles métier sur celui-ci. Est-ce un bon design d'avoir confiance en redis pub-sub pour cette utilisation? La durée de vie moyenne des touches sera de l'ordre de 15 minutes. En utilisant un autre design, j'aurai un scheduler/cron (toutes les minutes) ou un système d'interrogation.Utiliser redis pub-sub pour l'expiration de la clé
Merci Alok, pouvez-vous aider avec 1 chose de plus - dans la production, je vais avoir cette configuration dans plus d'une machine où l'abonné se déroulera dans toutes ces machines. Alors, quelle pourrait être la meilleure façon de gérer le même événement d'expiration afin que je ne rappelle pas d'autre système plus que pour l'expiration de la clé? – Ankush
Voulez-vous dire une configuration d'esclave maître en production ou en cluster. Dans le cas d'un cluster, ce ne sera pas un problème car une clé particulière ne serait stockée que sur une seule instance. Dans le cas d'une configuration maître/esclave, vous pouvez mettre l'abonné à l'écoute des événements uniquement à partir des instances principales. –
Non, je voulais dire que l'abonné sera dans une application Java qui s'abonnera aux événements d'expiration du maître redis. Maintenant, cette application sera déployée sur plusieurs machines, donc les événements d'expiration viendront à toutes les machines souscrites (car toutes les machines auront le même emballage et le même code d'abonné). À la réception de cet événement, je vais avoir un rappel à d'autres systèmes, alors comment puis-je gérer ce cas où je n'envoie pas de rappel de toutes les machines car ce sera la répétition des événements d'expiration. 1 façon est de déployer l'application abonné seulement dans 1 machine. Mais quel pourrait être le meilleur moyen? – Ankush