Nous utilisons Redis sur Trello pour les données éphémères que nous accepterions de perdre. Nous ne conservons pas les données dans Redis sur le disque, et nous les utilisons allkeys-lru, donc nous ne stockons que les choses là-bas qui peuvent être expulsées à tout moment avec seulement des inconvénients très mineurs pour les utilisateurs (par exemple, voir momentanément un statut d'utilisateur incorrect). Cela étant dit, nous lui donnons plus de 5 fois l'espace dont il a besoin pour stocker son jeu de travail réel et choisir parmi 10 clés pour l'expiration, de sorte que nous ne voyons vraiment rien se faire expulser que nous utilisons.
-
C'est notre serveur pubsub. Lorsqu'un utilisateur fait quelque chose sur un tableau ou une carte, nous voulons envoyer un message avec ce delta à tous les clients connectés au websocket qui sont abonnés à l'objet qui a changé, de sorte que tous nos processus Node sont abonnés à un canal pubsub qui se propage ces messages, et ils les propagent aux websockets dûment autorisés et abonnés.
-
Nous l'utilisons en SORTE pour sauvegarder socket.io, mais puisque nous n'utilisons que les websockets, et puisque socket.io est trop bavard pour évoluer comme nous en avons besoin pour le moment, nous avons un correctif qui désactive tous les canaux sauf le seul qui nous est nécessaire.
-
Pour nos utilisateurs qui n'ont pas de websockets, nous devons conserver une liste des actions qui se sont produites sur chaque canal d'objet depuis la dernière demande d'interrogation de l'utilisateur. Pour cela, nous utilisons une liste que nous plafonnons aux 100 éléments les plus récents, et un compteur auxiliaire du nombre d'éléments ajoutés à la liste depuis sa création. Ainsi, lorsque nous répondons à une demande d'interrogation d'un tel navigateur, nous pouvons vérifier le dernier élément qu'il signale avoir vu et n'envoyer que les messages qui ont été ajoutés à la file d'attente depuis lors. Ainsi, une demande de sondage se résume à une simple vérification des autorisations et à une seule vérification de clé Redis dans la plupart des cas, ce qui est très rapide.
-
Nous stockons certaines données éphémères sur le statut actif des utilisateurs connectés dans Redis, car ces données changent fréquemment et il n'est pas nécessaire de les conserver sur le disque.
-
Nous stockons des clés de courte durée pour prendre en charge les connexions OAuth dans Redis.
Nous aimons Redis ; une fois que vous en avez une instance opérationnelle, vous voulez l'utiliser pour toutes sortes de choses. Le seul véritable problème que nous ayons rencontré est que les clients lents consomment l'espace disponible.
Nous utilisons MongoDB pour nos besoins de base de données plus traditionnels.
