Le dernier article parlait de la fonction pipeline de redis et étendait certaines des opérations de base Linux à l'intérieur. Cet article complétera plusieurs fonctions avancées mentionnées au début de l'article précédent. L'article précédent disait que les fonctions avancées à enregistrer sont:
Pipeline
Transaction
Publish / Subscribe
Expiration
Bloom filter
Affaires
En plus des pipelines, redis a également des transactions, qui peuvent garantir l'atomicité d'un ensemble d'opérations dans une certaine mesure. L'utilisation principale multi, exec, watchet unwatchces mots - clés.
Une transaction commence par multi, puis de nombreuses instructions d'opération peuvent être exécutées jusqu'à ce qu'elle soit officiellement exécutée après avoir entré exec.
S'il y a deux clients, le client A entre d'abord multi, puis entre une série d'opérations redis, puis le client B entre multi, puis entre une série d'opérations, mais le client B exécute l'exécute en premier, le client A Après avoir exécuté exec, l'opération de B sera en fait exécutée en premier.
Bien sûr, une déclaration plus précise est que la séquence ci-dessus fait référence à l'heure reçue par le serveur. Pour des raisons de réseau et d'autres raisons, entrer d'abord ne signifie pas recevoir en premier.
Voici un exemple d'opération de transaction:
multi
set k1 111
get k1
exec
Outre les opérations ci-dessus, les transactions peuvent également être utilisées avec watch. Watch permet de surveiller les modifications d'une ou de plusieurs clés. Si la valeur de clé correspondante change pendant le processus de surveillance, l'exécution ultérieure de la transaction échouera, par exemple:
client1 écoute d'abord une clé, puis démarre la transaction, puis effectue certaines opérations, mais n'exécute pas exec
watch k1
multi
set k1 111
get k1
Puis client2 change la valeur de la clé
set k1 222
Ensuite, revenez à client1 et exécutez exec, vous constaterez que le résultat de retour est nul, ce qui signifie en fait que les données surveillées par watch ont changé, provoquant l'échec de la transaction entière.
Publier / s'abonner
Quand on parle de la structure de données de base de redis, il y a une fonction de blocage asynchrone dans la liste. L'utilisation blpopet les brpopcommandes peuvent bloquer le client jusqu'à ce que le résultat soit obtenu.
Cette fonction peut atteindre un contrôle et une consommation de messages similaires dans une certaine mesure, mais elle se termine dès que les données sont récupérées.
Et redis lui-même implémente le véritable communiqué de presse et la fonction d'abonnement, en utilisant publishet en subscribecommandant des opérations, par exemple: le
consommateur utilise l'abonnement pour surveiller un canal de canal:
subscribe channel1
Rouvrez une fenêtre de ligne de commande et utilisez publier pour publier des messages sur le canal supérieur:
publish channel1 hello
Après la publication, la première fenêtre ci-dessus recevra immédiatement le message et l'imprimera.
Bien que redis dispose d'une fonction de publication et d'abonnement, mais un autre problème existe, c'est-à-dire une fois que le client s'est abonné ou lorsque l'abonnement est activé, le message sera reçu. Si le client se déconnecte, il ne peut Après avoir reçu le message réinscrit après la reconnexion, le message pendant le processus de déconnexion sera toujours perdu.
Expiré
Bien que redis puisse être stocké de manière persistante, il est en fait utilisé comme cache dans la plupart des cas. Le cache est également un stockage temporaire. À cet égard, redis fournit une fonction très pratique, qui consiste à définir un délai d'expiration.
Il existe deux façons de définir le délai d'expiration. La première consiste à définir le délai d'expiration lors de la définition de la valeur. Cette méthode ne s'applique qu'au type chaîne. Il n'existe pas d'option de ce type pour les autres types d'opérations.
L'autre consiste à utiliser la fonction d'expiration pour définir un délai d'expiration pour la clé qui doit être définie sur timeout. Ceci est universel et peut être défini pour tout type pris en charge par redis.
Pour que les données de type chaîne définissent directement le délai d'expiration, il y aura deux paramètres facultatifs, l'un est l' exautre px, où ex représente les secondes et px représente les millisecondes, par exemple:
set k1 111 ex 2000
L'opération ci-dessus sauvera k1 en redis pendant 2000 secondes, tandis que l'opération ci-dessous ne sauvera que 2 secondes:
set k2 111 px 2000
Mais pour l'expiration générale, le paramètre milliseconde n'est pas pris en charge, et ce dernier ne peut être qu'en secondes, par exemple:
expire k1 2000
Ici, 2000 représente 2000 secondes, pas 2000 millisecondes.
Il convient de noter qu'une fonction importante du délai d'expiration de redis est de réduire le fonctionnement d'E / S de la base de données et qu'en raison de problèmes de ressources mémoire, le cache normal doit être des données chaudes et les données fréquemment utilisées sont des données chaudes.
Par conséquent, certaines personnes peuvent penser que les données lues fréquemment prolongeront automatiquement le délai d'expiration, mais la lecture des données ne prolonge pas le délai d'expiration des modifications.
Lorsque les données sont réécrites, l'heure d'expiration sera modifiée. Si l'heure d'expiration est à nouveau indiquée, elle deviendra la nouvelle heure d'expiration. Si la nouvelle heure d'expiration n'est pas indiquée, elle deviendra permanente jusqu'à ce que le service redis s'arrête. De plus, pour les données Le calcul ne changera pas le délai d'expiration.
Filtre Bloom
Comme mentionné ci-dessus, un rôle majeur de redis est de mettre en cache les données chaudes, réduisant ainsi les E / S fréquentes de la base de données, ce qui équivaut à une barrière avant la base de données, améliorant ainsi les performances globales et la disponibilité du système.
Ainsi, dans de nombreuses entreprises, il y aura une logique de vérifier la base de données si le cache ne peut pas être trouvé pour garantir l'intégrité et la fiabilité de l'entreprise.
Mais de cette manière, il n'y aura pas de cache redis, ni de base de données réelle. Ce scénario est appelé pénétration du cache redis. S'il y a un grand nombre de telles requêtes, il est concevable que la base de données soit sujette à des problèmes. Le filtre Bloom peut simplement résoudre le problème de la pénétration du cache dans une certaine mesure.
Le filtre Bloom n'est pas une fonction de base de redis, mais un module supplémentaire. Si vous souhaitez l'utiliser, vous devez d'abord le télécharger et le suspendre. Les étapes générales sont les suivantes
wget https://github.com/RedisBloom/RedisBloom/archive/master.zip
unzip master.zip
make
redis-server --loadmodule /opt/soft/rdisbloom.so
Inutile de dire que la première ligne mentionnée ci-dessus est le téléchargement wget de base de Linux. La deuxième étape de décompression du fichier zip ne devrait pas être dite. La troisième étape est de compiler le code source.
La quatrième étape est la clé, voici le filtre bloom lors du démarrage du service redis. Il convient de noter que le fichier so derrière est généré par make. Le chemin spécifique dépend de la situation et le chemin absolu doit être écrit .
Bien sûr, ce contenu peut également être configuré dans le fichier de configuration redis, il n'est donc pas nécessaire de le configurer manuellement chaque fois que vous le démarrez.
Avec les opérations ci-dessus, vous pouvez utiliser le filtre Bloom. Il existe trois opérations clés, à savoir bf.add, bf.existset bf.reserve. Le rôle d'ajout est d'ajouter du contenu au filtre. Exists est utilisé pour déterminer s'il existe, et reserve peut définir le taux d'erreur. Et la capacité estimée est gérée de manière personnalisée, l'exemple est le suivant:
bf.add filter1 111
bf.exists filter1 111
bf.reserve filter2 0.01 100
Le filtre1 et le filtre2 ci-dessus peuvent être compris comme le nom du filtre. Lorsque vous utilisez existe pour déterminer, certains des filtres renverront 1, et s'il n'y en a pas, ils renverront 0.
Pour réserver, en plus du nom du filtre, un taux d'erreur est également requis. , Une capacité estimée, plus le taux d'erreur est bas, plus l'espace de stockage consommé est grand et les données réelles dépassent la capacité estimée, le taux de faux positifs augmentera.
Dans le même temps, il convient de noter que la réserve ne peut être utilisée que sur des filtres qui n'existent pas encore. Effectuer cette opération sur des filtres existants lèvera une exception.
Le stockage sous-jacent du filtre Bloom utilise le stockage octet-bit comme une image bitmap. Il peut y avoir plusieurs données occupant le même bit, ce qui entraîne également un certain taux d'erreur de jugement. Le résultat de l'erreur de jugement est le suivant: le filtre Bloom renvoie un certain nombre qui n'existe pas. S'il n'existe pas, le filtre Bloom retourne à l'existence qui n'existe pas forcément.
Le stockage des données du filtre Bloom rend l'espace commun, ce qui économise considérablement l'espace de stockage. Cependant, il existe également un partage, ce qui conduit à l'interdiction de supprimer des éléments dans le filtre. Par conséquent, l'inquiétant de Bloom ne peut pas trouver l'opération de suppression d'élément. Selon le site en ligne On dit que le filtre coucou peut gérer ce type de problème, nous allons donc arrêter temporairement l'expansion ici.
Articles Liés
Connaissances de base liées à la mise en cache et à Redis
Installation de Redis Linux et à l'installation de logiciels Points de connaissance Linux
relatifs au type de données Redis Connaissances clés et scénarios d'application
Redis Pipeline, transaction, publication et abonnement, expiration, filtre et autres fonctions avancées courantes (partie 1)
Redis pipeline, Une petite note des fonctions avancées couramment utilisées telles que les transactions, la publication et l'abonnement, l'expiration, les filtres, etc. (Partie 2)
Intégration de Springboot et utilisation des fonctions communes de Redis