À quoi sert Redis généralement dans Java Web ?

De manière générale, il existe deux scénarios principaux pour Redis dans les applications Web Java. L'un consiste à mettre en cache les données couramment utilisées et l'autre consiste à les utiliser pour lire/écrire rapidement lorsqu'une lecture/écriture à grande vitesse est requise. . Par exemple, il y a des occasions où il faut se précipiter pour acheter des marchandises et récupérer des enveloppes rouges.

En raison de la lecture/écriture à grande vitesse des données dans des conditions de concurrence élevée, l'un des problèmes fondamentaux est la cohérence des données et le contrôle d'accès.

Caches (Apprentissage recommandé : Tutoriel vidéo Redis )

Dans l'opération de lecture/écriture de la base de données, la réalité est La Le nombre d'opérations de lecture dépasse de loin le nombre d'opérations d'écriture, généralement dans un rapport de 1:9 à 3:7, de sorte que la possibilité de lire est bien supérieure à la possibilité d'écrire.

Lors de l'envoi de SQL à la base de données pour lecture, la base de données ira sur le disque pour indexer les données correspondantes, et l'indexation du disque est un processus relativement lent. Si les données sont placées directement sur le serveur Redis s'exécutant dans la mémoire, alors il n'est pas nécessaire de lire/écrire le disque, mais de lire directement la mémoire, ce qui sera évidemment beaucoup plus rapide et réduira considérablement la pression sur la base de données.

Le coût d'utilisation de la mémoire pour stocker des données est également relativement élevé, car les disques peuvent être de niveau TGB et sont très bon marché. La mémoire est généralement de quelques centaines de Go, ce qui est donc assez impressionnant, même si la mémoire est efficace. l'espace est limité et le prix Il est également beaucoup plus élevé que le disque, donc le coût d'utilisation de la mémoire est élevé Il n'est pas possible de stocker ce que vous voulez, nous devrions donc envisager un stockage conditionnel des données.

De manière générale, certaines données couramment utilisées sont stockées, telles que les informations de connexion des utilisateurs ; certaines informations commerciales importantes, telles que les banques stockeront des informations de base sur les clients, des informations sur les cartes bancaires, des informations sur les transactions récentes, etc. De manière générale, lorsque vous utilisez le stockage Redis, vous devez prendre en compte trois aspects.

Les données commerciales sont-elles couramment utilisées ? Quel est le taux de réussite ? Si le taux de réussite est faible, il n'est pas nécessaire d'écrire dans le cache. Que les données métier comportent de nombreuses opérations de lecture ou d'écriture ? S'il y a beaucoup d'opérations d'écriture, elles doivent être écrites fréquemment dans la base de données et il n'est pas nécessaire d'utiliser le cache. Quelle est la taille des données d’entreprise ? Si vous souhaitez stocker des centaines de mégaoctets de fichiers, cela mettra beaucoup de pression sur le cache. Est-ce nécessaire ?

Après avoir examiné ces problèmes, si vous estimez que la mise en cache est nécessaire, utilisez-la. La logique de lecture pour l'utilisation de Redis comme cache est illustrée à la figure 1.

À partir de la figure 1, nous pouvons connaître les deux points suivants.

Lors de la première lecture des données, la lecture des données Redis échouera. À ce moment-là, le programme sera déclenché pour lire la base de données, lire les données et les écrire dans Redis.

Lorsque les données sont lues pour la deuxième fois et par la suite, Redis est lu directement. Une fois les données lues, le processus se termine, la vitesse est donc grandement améliorée.

D'après l'analyse ci-dessus, nous pouvons voir que la plupart des opérations sont des opérations de lecture. L'utilisation de Redis pour gérer les opérations de lecture sera très rapide, tout en réduisant également la dépendance à l'égard de la base de données et en réduisant considérablement la charge sur la base de données.

Après avoir analysé la logique de l'opération de lecture, analysons le processus de l'opération d'écriture, comme le montre la figure 2.

Comme le montre le processus, les opérations de mise à jour ou d'écriture nécessitent plusieurs opérations Redis. Si le nombre d’écritures de données métiers est bien supérieur au nombre de lectures, il n’est pas nécessaire d’utiliser Redis.

Si le nombre de lectures est bien supérieur au nombre d'écritures, alors utiliser Redis a sa valeur, car même si l'écriture sur Redis coûte une certaine somme d'argent, ses performances sont bonnes et sont presque négligeables par rapport à base de données.

Occasions de lecture/écriture à grande vitesse

Dans les applications Internet, certaines occasions nécessitent souvent une lecture/écriture à grande vitesse, telles que les ventes flash de produits, récupérer des enveloppes rouges, Taobao, l'événement Double Eleven de JD.com ou la vente de billets pour la Fête du Printemps, etc.

Dans les situations ci-dessus, des milliers de requêtes atteindront le serveur en un instant. Si une base de données est utilisée, la base de données devra exécuter des milliers de SQL en un instant, ce qui peut facilement provoquer un goulot d'étranglement dans la base de données. Sérieusement, cela entraînerait une paralysie de la base de données et un crash du service système Java.

La réponse à de telles situations consiste souvent à envisager l'écriture asynchrone dans la base de données et, dans les situations de lecture/écriture à grande vitesse, à utiliser Redis seul pour mettre en cache les données qui nécessitent une lecture/écriture à grande vitesse dans Redis. et lorsque certaines conditions sont remplies, ces données mises en cache sont déclenchées pour être écrites dans la base de données. Examinons d'abord l'organigramme d'une opération de requête, comme le montre la figure 3.

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!