Sur la base de la réponse de @ybak, je vais vous proposer une solution relativement simple et pratique.
Limitez la mémoire occupée par Redis. Redis chargera les données chaudes en mémoire selon sa propre stratégie d'élimination des données. Alors, calculez la mémoire approximative occupée par 20 W de données, puis définissez la limite de mémoire Redis.
Telles que les données utilisateur. La base de données compte 20 millions d'entrées. Utilisateurs actifs : Insérez dans le tri Redis, les utilisateurs qui se sont connectés dans les deux jours (pour plus de commodité, les utilisateurs actifs dans la journée) sont connectés une fois à ZADD. Si l'ensemble existe déjà, son score (heure de connexion) est enregistré. sera écrasé. Clé : connexion : utilisateurs, valeur : horodatage du score, valeur ID utilisateur. Configurez une tâche périodique, telle que la suppression des données dans l'ensemble de tri avant 15 heures la veille à 03h00:00 tous les jours (pour garantir que l'ensemble ne se développe pas de manière désordonnée et retient les utilisateurs actifs au cours de la journée écoulée). ).
Lors de la récupération, obtenez l'horodatage actuel (à 10 chiffres), puis soustrayez 1 jour pour obtenir les utilisateurs actifs au cours des dernières 24 heures en fonction de la plage de scores.
En regardant votre question, vous devriez simplement utiliser Redis comme cache Fournissez un moyen simple d'implémenter l'invalidation du cache : LRU (obsolescence récemment rarement utilisée) Autrement dit, chaque fois que le cache Redis arrive, ajoutez. un certain ttl (délai d'expiration) au cache des hits (défini en fonction de la situation spécifique, par exemple 10 minutes Après un certain temps, le ttl des données chaudes sera plus grand et n'expirera pas automatiquement, tandis que). les données froides expireront essentiellement. Le ttl défini deviendra immédiatement invalide.
Lorsque la taille de l'ensemble de données de la mémoire Redis augmente jusqu'à une certaine taille, une stratégie d'élimination des données sera mise en œuvre.
redis propose 6 stratégies d'élimination des données :
volatile-lru : sélectionnez les données les moins récemment utilisées dans l'ensemble de données avec un délai d'expiration pour éliminer volatile-ttl volatile-random allkeys-lru allkeys -aléatoire pas d'enviction
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Sur la base de la réponse de @ybak, je vais vous proposer une solution relativement simple et pratique.
Limitez la mémoire occupée par Redis. Redis chargera les données chaudes en mémoire selon sa propre stratégie d'élimination des données.
Alors, calculez la mémoire approximative occupée par 20 W de données, puis définissez la limite de mémoire Redis.
Quelles sont les données qui posent problème ?
Telles que les données utilisateur. La base de données compte 20 millions d'entrées.
Utilisateurs actifs :
Insérez dans le tri Redis, les utilisateurs qui se sont connectés dans les deux jours (pour plus de commodité, les utilisateurs actifs dans la journée) sont connectés une fois à ZADD. Si l'ensemble existe déjà, son score (heure de connexion) est enregistré. sera écrasé. Clé : connexion : utilisateurs, valeur : horodatage du score, valeur ID utilisateur. Configurez une tâche périodique, telle que la suppression des données dans l'ensemble de tri avant 15 heures la veille à 03h00:00 tous les jours (pour garantir que l'ensemble ne se développe pas de manière désordonnée et retient les utilisateurs actifs au cours de la journée écoulée). ).
Lors de la récupération, obtenez l'horodatage actuel (à 10 chiffres), puis soustrayez 1 jour pour obtenir les utilisateurs actifs au cours des dernières 24 heures en fonction de la plage de scores.
En regardant votre question, vous devriez simplement utiliser Redis comme cache
Fournissez un moyen simple d'implémenter l'invalidation du cache : LRU (obsolescence récemment rarement utilisée)
Autrement dit, chaque fois que le cache Redis arrive, ajoutez. un certain ttl (délai d'expiration) au cache des hits (défini en fonction de la situation spécifique, par exemple 10 minutes
Après un certain temps, le ttl des données chaudes sera plus grand et n'expirera pas automatiquement, tandis que). les données froides expireront essentiellement. Le ttl défini deviendra immédiatement invalide.
Lorsque la taille de l'ensemble de données de la mémoire Redis augmente jusqu'à une certaine taille, une stratégie d'élimination des données sera mise en œuvre.
redis propose 6 stratégies d'élimination des données :
volatile-lru : sélectionnez les données les moins récemment utilisées dans l'ensemble de données avec un délai d'expiration pour éliminer
volatile-ttl
volatile-random
allkeys-lru
allkeys -aléatoire
pas d'enviction