10 conseils d'utilisation de Redis

Redis est très populaire dans la communauté technologique actuelle. Redis a parcouru un long chemin depuis un petit projet personnel d'Antirez jusqu'à devenir la norme industrielle en matière de stockage de données en mémoire. L’ensemble de bonnes pratiques qui en résulte permet à la plupart des gens d’utiliser correctement Redis.

1. Arrêtez d'utiliser KEYS *

D'accord, commencer cet article en contestant cette commande n'est peut-être pas un bon moyen, mais c'est effectivement possible. point le plus important. Souvent, lorsque nous prêtons attention aux statistiques d'une instance Redis, nous entrerons rapidement la commande "KEYS *" afin que les informations clés soient clairement affichées.

D'un point de vue programmation, nous avons tendance à écrire un pseudocode comme celui-ci :

for key in'keys *':
  doAllTheThings()　　

Mais lorsque vous disposez de 13 millions de clés, la vitesse d'exécution va ralentir. Étant donné que la complexité temporelle de la commande KEYS est O(n), où n est le nombre de clés à renvoyer, la complexité de cette commande dépend de la taille de la base de données. Et lors de l’exécution de cette opération, aucune autre commande ne pourra être exécutée dans votre instance.

Comme commande alternative, jetez un œil à SCAN, qui vous permet d'effectuer de manière plus conviviale... SCAN analyse la base de données dans une itération incrémentielle. Cette opération est effectuée en fonction de l'itérateur du curseur, vous pouvez donc arrêter ou continuer à tout moment comme bon vous semble.

2. Découvrez le coupable qui ralentit Redis

Étant donné que Redis n'a pas de journaux très détaillés, il est très difficile de savoir ce qui se fait dans l'instance Redis. Heureusement, Redis fournit un outil de statistiques de commandes comme le suivant :

127.0.0.1:6379> INFO commandstats
# Commandstats
cmdstat_get:calls=78,usec=608,usec_per_call=7.79
cmdstat_setex:calls=5,usec=71,usec_per_call=14.20
cmdstat_keys:calls=2,usec=42,usec_per_call=21.00
cmdstat_info:calls=10,usec=1931,usec_per_call=193.10

En utilisant cet outil, vous pouvez afficher des instantanés de toutes les statistiques de commandes, telles que le nombre de fois que la commande a été exécutée et le nombre de millisecondes qu'il a fallu pour exécutez la commande (chaque commande Le temps total et le temps moyen)

Il vous suffit d'exécuter simplement la commande CONFIG RESETSTAT pour la réinitialiser, afin d'obtenir un tout nouveau résultat statistique.

3. Utilisez les résultats de Redis-Benchmark comme référence au lieu de généraliser

Salvatore, le père de Redis, a déclaré : "Tester Redis en exécutant des commandes GET/SET, c'est comme tester une Ferrari sur un jour de pluie. L'effet d'un essuie-glace nettoyant un miroir. Souvent, les gens viennent me voir et veulent savoir pourquoi leurs statistiques Redis-Benchmark sont inférieures aux résultats optimaux. Mais nous devons prendre en considération diverses situations réelles

Par exemple :

• Quelles sont les restrictions de l'environnement d'exploitation du client ? Est-ce que

• a le même numéro de version ?

• Les performances dans l'environnement de test sont-elles cohérentes avec l'environnement dans lequel l'application sera exécutée ?

Les résultats des tests de Redis-Benchmark fournissent un point de référence pour garantir que votre Redis-Server ne fonctionnera pas dans un état anormal, mais vous ne devez jamais le prendre comme un véritable " Test de stress ». Les tests de résistance doivent refléter le fonctionnement de l'application et nécessitent un environnement aussi similaire que possible à la production.

4. Les hachages sont votre meilleur choix

Introduisez les hachages de manière élégante. Les hachages vous apporteront une expérience inédite. J'ai déjà vu de nombreuses structures de clés similaires à celles-ci :

foo:first_name
foo:last_name
foo:address

Dans l'exemple ci-dessus, foo peut être le nom d'utilisateur d'un utilisateur, et chaque élément qu'il contient est une clé distincte. Cela augmente la marge d’erreur et les clés inutiles. Utilisez plutôt hash, vous serez surpris de constater que vous n'avez besoin que d'une seule clé :

127.0.0.1:6379> HSET foo first_name 'Joe'
(integer) 1
127.0.0.1:6379> HSET foo last_name 'Engel'
(integer) 1
127.0.0.1:6379> HSET foo address '1 Fanatical Pl'
(integer) 1
127.0.0.1:6379> HGETALL foo
1) 'first_name'
2) 'Joe'
3) 'last_name'
4) 'Engel'
5) 'address'
6) '1 Fanatical Pl'
127.0.0.1:6379> HGET foo first_name
'Joe'

5 Définissez le temps de survie de la valeur clé

Dans la mesure du possible, profitez du délai d'attente de la clé. Un bon exemple consiste à stocker quelque chose comme une clé d'authentification temporaire. Lorsque vous recherchez une clé d'autorisation - prenez OAUTH comme exemple - vous obtenez généralement un délai d'attente.

De cette façon, lors de la définition de la clé, réglez-la sur le même délai d'attente, et Redis l'effacera automatiquement pour vous ! Il n'est plus nécessaire d'utiliser KEYS * pour parcourir toutes les touches. Quelle commodité ?

6. Choisissez une stratégie de recyclage adaptée

Maintenant que nous avons parlé du nettoyage des clés, parlons des stratégies de recyclage. Lorsque l'espace de l'instance Redis est rempli, il tentera de récupérer certaines clés. En fonction de votre utilisation, je vous recommande fortement d'utiliser la stratégie volatile-lru - à condition d'avoir défini un délai d'attente sur la clé.

Mais si vous exécutez quelque chose de similaire au cache et que vous ne définissez pas de mécanisme de délai d'attente pour les clés, vous pouvez envisager d'utiliser le mécanisme de recyclage allkeys-lru.

7. Si vos données sont importantes, veuillez utiliser Try/Except

Si vous devez vous assurer que les données critiques peuvent être placées dans une instance Redis, je vous recommande fortement de les mettre dans un try/ sauf bloc. Presque tous les clients Redis adoptent la stratégie « envoyer et oublier », il est donc souvent nécessaire de se demander si une clé est réellement placée dans la base de données Redis.

En ce qui concerne la complexité de mettre try/expect dans la commande Redis, cet article n'en parle pas. Vous devez juste savoir que cela peut garantir que les données importantes sont placées là où elles devraient être.

8. N'épuisez pas une instance

Dans la mesure du possible, répartissez la charge de travail sur plusieurs instances Redis. À partir de la version 3.0.0, Redis prend en charge les clusters. Redis Cluster vous permet de séparer certaines clés contenant des modes maître/esclave en fonction de plages de clés. La « magie » complète derrière le clustering peut être trouvée ici.

Mais si vous recherchez des tutoriels, alors c'est l'endroit parfait. Si le clustering n'est pas une option, envisagez les espaces de noms et répartissez vos clés sur plusieurs instances.

9. Est-il préférable d'avoir plus de cœurs ? !

Bien sûr, c'est faux. Redis est un processus monothread et ne consomme qu'un maximum de deux cœurs, même avec la persistance activée. À moins que vous n'envisagiez d'exécuter plusieurs instances sur un seul hôte - espérons-le uniquement dans un environnement de développement et de test ! ——Sinon, il n'est pas nécessaire de disposer de plus de 2 cœurs pour une instance Redis.

10. Haute disponibilité

Jusqu'à présent, Redis Sentinel a été minutieusement testé et de nombreux utilisateurs l'ont appliqué à des environnements de production (y compris ObjectRocket). Si votre application s'appuie fortement sur Redis, vous devez proposer une solution haute disponibilité pour vous assurer qu'elle ne se déconnecte pas.

Pour plus de connaissances connexes, veuillez prêter attention à la colonne Tutoriel de base Java

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!