Redis est un cache, mais ce n'est pas pour ça que j'en ai besoin

Redis est généralement introduit comme un cache. Son rôle plus important dans ma stack est la couche d'état partagé qui laisse plusieurs instances back-end et connexions websocket se coordonner — précisément comme l'adaptateur qui adosse le pub/sub inter-instances de Socket.io.

Sans lui, la messagerie temps réel ne marche qu'avec une seule instance. Dès qu'il y en a plus d'une derrière un load balancer, un message d'un utilisateur sur l'instance A n'atteint jamais un destinataire sur l'instance B, et rien nulle part ne te dit qu'il est parti dans le vide.

J'utilise ioredis plutôt que le plus simple node-redis pour un fort support TypeScript, un support cluster/sentinel intégré s'il faut un jour monter au-delà d'un nœud, et parce que @socket.io/redis-adapter l'attend.

Ce que l'adaptateur corrige

Socket.io garde l'appartenance aux rooms dans la mémoire d'un seul processus par défaut. Avec une instance, c'est bon. Avec plus d'une — normal pour l'échelle et pour les déploiements sans coupure — chaque instance ne connaît que ses propres connexions. L'adaptateur Redis fait publier par chaque instance les événements émis sur un canal pub/sub partagé, pour qu'un emit sur l'instance A se ventile via Redis vers l'instance B, qui livre à ses propres sockets locaux. C'est ce qui fait que « admin sur le serveur A et utilisateur sur le serveur B se messagent en direct » marche réellement.

Autres usages naturels : les compteurs de limitation de débit qui ont besoin de vivre quelque part de partagé plutôt que dans la mémoire locale de chaque instance ; mettre en cache les recherches de token_version avec un TTL court pour que chaque requête authentifiée ne frappe pas la base ; le suivi de présence pour les accusés de lecture ou les indicateurs « actif maintenant ».

Le modèle mental

Redis est rapide parce qu'il est en mémoire, ce qui est aussi sa contrainte. Ne le traite pas comme durable pour quoi que ce soit que tu ne peux pas te permettre de perdre au redémarrage ou à l'éviction, à moins qu'il ne soit explicitement configuré pour la persistance. Chaque rôle que Redis joue ici — pub/sub, limites de débit, cache — est acceptable à perdre et à reconstruire. La source de vérité de tout ce qui est durable reste dans Postgres. (J'ai bien une fois livré Redis sur sa politique d'éviction par défaut alors qu'il tenait des jetons de sécurité et des compteurs de limitation de débit — sous pression mémoire, il en lâchait un silencieusement. Maintenant c'est noeviction, avec un test smoke CI qui l'affirme.)