Comment tester Redis ?

Des amis testeurs sont venus me demander, comment tester Redis ? Tout d’abord, nous devons savoir, qu’est-ce que Redis ? Qu'est-ce que ça peut faire

Redis est une base de données de stockage à grande vitesse de type clé-valeur.

Redis est souvent utilisé comme : cache, file d'attente, publication et abonnement, etc.

Ainsi, la question « comment tester Redis ? » peut se transformer en :

Comment tester le cache ?

Comment tester la file d'attente ?

Comment tester l'abonnement ?

Dans la pile technologique avec laquelle j'ai été en contact, redis est rarement utilisé pour la publication et l'abonnement.Parlons principalement du cache et de la file d'attente.

01. Classement des caches

Il existe plusieurs types de caches : les caches de fichiers, les caches de bases de données, les caches mémoire, les caches de navigateur.

La mise en cache du navigateur fait référence aux propres capacités de mise en cache du navigateur. Afin d'accélérer le chargement des pages, les navigateurs modernes téléchargent souvent une fois les fichiers de ressources tels que CSS et JS, puis les mettent en cache pendant un certain temps jusqu'à ce que le cache échoue ou que la demande informe explicitement qu'ils doivent être mis à jour.

Si l'interface est générée via le rendu direct du langage back-end , smarty et d'autres méthodes de rendu de modèles , le cache de type de fichier est généralement sélectionné.

Avec le développement rapide de la grande technologie front-end, la séparation du front-end et du back-end devient de plus en plus populaire, et la méthode de rendu intelligente est de moins en moins utilisée, et les exigences de temps de réponse de l'interface pour les services back-end sont De plus en plus, la mise en cache des fichiers n'est plus adaptée à ce scénario. La mise en cache des bases de données devient de plus en plus populaire.

La mise en cache des bases de données est actuellement la plus courante : redis et memcached. Ce sont tous deux des systèmes de cache clé-valeur distribués.

Le cache mémoire est similaire au cache de base de données, mais limité par la pile technologique. Par exemple, Java peut être utilisé, et Java est utilisé très fréquemment, mais PHP ne peut pas être utilisé. Le cache mémoire est plus rapide que le cache de base de données, mais comme la mémoire ne peut pas être augmentée à tout moment, elle a plus de restrictions et des problèmes tels que des fuites de mémoire se produiront si vous n'y prêtez pas attention.

En utilisation réelle, l'interface Java place souvent certaines données haute fréquence dans le cache mémoire en tant que cache de premier niveau, et place les données sous-haute fréquence dans Redis en tant que cache de deuxième niveau, et enfin interroge les données du db.

Le rôle du cache :

D'après le contenu ci-dessus, vous savez peut-être déjà que les deux fonctions les plus importantes de la mise en cache sont : accélérer l'accès et réduire la pression sur le serveur et la base de données.

02. Scénarios d'utilisation de la mise en cache

Vous vous demandez peut-être, ce qui précède n’a rien à voir avec les tests ? Non, je pense que connaître ce qui précède est toujours utile pour les tests. Savez-vous quand ajouter du cache et quand ne pas ajouter de cache en termes de mise en œuvre technique ? Il s’agit du contrôle technique d’une interface, qui doit être connu non seulement des développeurs, mais aussi des testeurs.

Ne vous sentez-vous pas fier si vous découvrez une interface qui devrait ajouter du cache sans ajouter de cache avant le test de pression ? En fait, cela correspond au rôle du cache un par un. Lorsque le qps de l'interface est élevé (par exemple, supérieur à 100) ou qu'il y a une exigence de vitesse de réponse, ou que les performances du serveur et de la base de données sont mauvaises, vous pouvez essayer d'utiliser le cache pour résoudre le problème.

Permettez-moi de donner quelques exemples:

1. Dans la nouvelle version de WeChat, il existe une fonction « statut » supplémentaire dans le centre personnel.

Le nombre d'utilisateurs de WeChat est très important et le qps d'accès est très élevé. Des centaines de milliers de personnes visitent en même temps et il est impossible d'interroger la base de données à chaque fois.

Semblable à ce type de demande, l'approche générale est la suivante : mettez d'abord en cache les données d'état de l'utilisateur dans l'application (cache du navigateur), puis appelez l'interface back-end pour demander les données « d'état » en poussant ou en extrayant passivement pendant une certaine période de temps. time ;L'interface lit les données du cache redis/memcached et les renvoie ; si la quantité de données n'est pas si grande, l'interface peut directement lire les données du cache mémoire et les renvoyer ; une fois les données renvoyées, le cache dans le l'application utilisateur est mise à jour.

2. Il existe une page de liste d'arrière-plan de gestion de produits d'une petite entreprise de commerce électronique. Le nombre de visiteurs n'est pas important et la fréquence des changements de SKU est très faible. Elle peut être visitée des dizaines de fois en 3 jours. Ce type de scénario n'a pas besoin d'utiliser la mise en cache, et deuxièmement, vous devez voir les données mises à jour immédiatement après la mise à jour des informations sur le produit, ce qui ne convient pas à la mise en cache, il n'est donc pas recommandé d'utiliser la mise en cache.

3. Même fond de gestion du e-commerce, il s'agit cette fois d'une page de statistiques, qui compte les ventes de marchandises hier/aujourd'hui/près d'une semaine.

Il existe de nombreuses solutions différentes pour ce scénario.

(Nous mettons de côté diverses solutions techniques pour les statistiques Big Data, et réalisons simplement la fonction statistique d'un système)

Pas besoin de statistiques en temps réel

Vous n'avez besoin de faire des statistiques régulières qu'une seule fois, par exemple, vous n'avez besoin que de regarder les données statistiques d'hier : elles peuvent être directement stockées dans la base de données une fois les données statistiques comptées par le script planifié, et vous pouvez directement interroger la base de données. quand vous avez besoin de consulter les données statistiques

Besoin d'interroger des statistiques en temps réel

Cependant, l'efficacité d'exécution de chaque SQL statistique qui doit être interrogé répond aux attentes : vous pouvez interroger directement la base de données à chaque fois que vous consultez les données, et la base de données n'est pas soumise à beaucoup de pression pour le moment.

Besoin d'interroger des statistiques en temps réel

Et en raison de l'énorme quantité de données commerciales, l'efficacité d'exécution de chaque SQL statistique est très faible ou ne peut pas être directement comptée : vous pouvez résumer chaque indicateur et conserver la valeur statistique dans le cache. Par exemple, si vous avez besoin d'informations sur les ventes, chaque fois qu'un le produit est vendu, le cache des statistiques de ventes +1, lors de la visualisation des données statistiques, vous pouvez interroger le cache à ce moment

03. Comment générer du cache

Après avoir compris les scénarios d'utilisation du cache, parlons de la façon dont le cache est généré.

De manière générale, il existe deux manières d'utiliser le cache, que je résume brièvement ainsi : à l'extérieur et à l'intérieur .

Tout d’abord, parlons de la façon dont une demande d’interface est traitée dans le programme :

Il s'agit d'un MVC typique, le contrôleur reçoit et traite les données de la demande, le service traite les données obtenues dans le modèle, puis la vue les génère.

Pour différents scénarios, nous pouvons utiliser plusieurs manières pour ajouter différents caches sur plusieurs nœuds afin de résoudre différents problèmes.

Par exemple, en réponse à la modification des paramètres de la requête, si les données renvoyées sont fortement liées aux paramètres de la requête, il convient de mettre en cache les données interrogées « à l'extérieur » (une fois les paramètres de la requête filtrés). Ce type de données est généralement mis en cache pendant une courte période, par exemple 5 minutes. Il traite principalement des requêtes répétées avec les mêmes paramètres de requête sur une courte période de temps. Si vous rencontrez une attaque par requête, même si la durée de validité du cache n'est que de 1 seconde, elle reste très efficace et peut bloquer un grand nombre de requêtes.

Par exemple, dans le cas où les paramètres de la requête ne changent pas beaucoup et que les données renvoyées sont très proches des données stockées dans la base de données, il convient de mettre en cache les données "à l'intérieur", c'est-à-dire de mettre à jour le cache tout en mettant à jour la base de données. Dans l'état optimal de cette situation, il suffit de lire le cache et il n'est pas nécessaire d'interagir directement avec la base de données, ce qui peut grandement soulager la pression sur la base de données. Cette durée de validité du cache peut être fixée très longue.

04. Comment mettre à jour le cache

Après avoir parlé de la génération, parlons de la mise à jour du cache. Une fois le cache généré, il ne restera normalement pas inchangé, le cache doit donc être mis à jour.

Il existe plusieurs façons de mettre à jour :

• Renouvellement automatique après expiration : c'est la façon la plus paresseuse de renouveler. En définissant la période de validité du cache, un nouveau cache est automatiquement créé via une nouvelle demande après l'expiration du cache.

• Supprimer le cache : après avoir mis à jour les données de la base de données, supprimez le cache directement et créez automatiquement un nouveau cache via une nouvelle requête.

• Réinitialiser le cache : Après avoir mis à jour les données de la base de données, réinitialisez directement le cache.

05. Point de test du cache Redis

1. Angle de test de performances

Si la fonction d'augmentation/mise à jour du cache est correcte, vérifiez si les données du cache sont correctes

• Ajouter des journaux associés, afficher les journaux

• outil de porte dérobée

• À l'aide de la ligne de commande, Memcached et Reids peuvent se connecter et visualiser directement

suppression du cache

• Cache valide, vérifier les fonctions métier associées

• Le cache est supprimé et les fonctions métier pertinentes sont vérifiées

• Le cache expire et expire, memcached et redis peuvent définir le délai d'expiration, vérifier s'il y a un délai d'expiration, n'est-ce pas ?

Mécanisme d'élimination excessive : que faire lorsque le cache atteint la limite supérieure

pénétration du cache

avalanche de cache

service de cache Redis arrêté

délai d'expiration du cache

Une fois les données mises en cache modifiées par erreur, restaurez rapidement la version spécifiée

Une fois les données du cache supprimées par erreur, restaurez rapidement les données

2. Angle de test de la fonction Redis

• Lorsque les données Redis prennent effet, la lecture est-elle correcte ?

• Les données Redis n'existent pas, pouvez-vous lire normalement la valeur correcte de la base de données, l'écrire dans Redis et la renvoyer à la couche supérieure

• Les performances sont-elles normales lorsque les données n'existent pas dans Redis et DB ?

• Lors de la suppression de données, les données dans Redis et DB sont-elles cohérentes ?

Enfin, je voudrais remercier tous ceux qui ont lu attentivement mon article. La réciprocité est toujours nécessaire. Bien que ce ne soit pas une chose de très grande valeur, vous pouvez la retirer si vous en avez besoin :

Applet d'entretien de test logiciel

La banque de questions de tests logiciels optimisée par des millions de personnes ! ! ! Qui est qui sait ! ! ! Le mini programme de quiz le plus complet de tout le réseau, vous pouvez utiliser votre téléphone portable pour faire les quiz, dans le métro ou dans le bus, roulez-le !

Les sections de questions d'entretien suivantes sont couvertes :

1. Théorie de base des tests logiciels, 2. Web, applications, tests de fonctions d'interface, 3. réseau, 4. base de données, 5. Linux

6. Web, application, automatisation de l'interface, 7. tests de performances, 8. bases de la programmation, 9. questions d'entretien RH, 10. questions de test ouvertes, 11. tests de sécurité, 12. bases de l'informatique

Ces matériaux devraient constituer l'entrepôt de préparation le plus complet et le plus complet pour les amis [des tests de logiciels]. Cet entrepôt a également accompagné des dizaines de milliers d'ingénieurs de test tout au long du voyage le plus difficile. J'espère qu'il pourra vous aider aussi !