Brève description de la structure de données
Redis Redis a cinq structures de données communes, trois structures de données spéciales (non expliquées ici)
des structures de données couramment utilisées:
STRING:
C'est un objet implémenté par des valeurs entières et SDS (chaîne dynamique simple).
Scénarios d'application:
1 Peut être utilisé comme cache
2. Peut être utilisé comme compteur
3. Peut être utilisé comme session utilisateur partagée
HASH: Il s'agit d'un
scénario d'application d' objet de hachage implémenté par des listes compressées et des dictionnaires :
1. Il peut être utilisé comme stockage de base de données relationnelle pour stocker des informations relatives à l'utilisateur.
LISTE: Il s'agit d'une
application d' objet de liste implémentée par des listes compressées et des listes liées à double extrémité Scénario:
1. Il peut être utilisé comme file d'attente de messages pour obtenir une file d'attente de blocage, via la commande left in et right out
. 2. Il peut être utilisé comme une pagination de données, comme la liste d'articles d'un utilisateur sur un blog
SET: C'est un
scénario d'application d' objet de collection réalisé par une collection d'entiers et un dictionnaire :
1. Libellé
2. Ami commun
3. IP indépendant
ZSET: Il s'agit d'un ensemble ordonné d'objets implémentés par des listes compressées, des dictionnaires et des tables de saut.
Scénarios d'application:
1. Classement, qui peut être trié selon un certain champ
2. Calculer les poids, définir les valeurs de poids et laisser les threads s'exécuter selon les règles de pondération
Décrivez brièvement le mécanisme de persistance RDB et AOF de Redis
Les deux sont le mécanisme de persistance de redis
RDB est une persistance au niveau de l'instantané, qui est conservée sous la forme d'un fichier de flux binaire via la commande save et la commande bgsave. Lorsque la commande de sauvegarde est exécutée, le processus du serveur Redis est bloqué. Avant la génération du fichier RDB, le serveur Redis ne peut pas exécuter d'autres commandes pour demander des opérations. Lorsque la commande bgsave est exécutée, le serveur Redis forkera un processus enfant pour effectuer la génération du fichier RDB. , Ce qui équivaut à s'exécuter en arrière-plan. À ce stade, le serveur Redis est dans un état non bloquant. Il peut effectuer les opérations demandées par d'autres commandes. Notez que Redis ne permet pas au processus principal et aux processus enfants d'exécuter des commandes save ou bgsave en même temps, afin d'empêcher les principales Le processus et le processus enfant ont une relation concurrentielle.
AOF correspond à la persistance au niveau du journal. Il ajoute les commandes d'exploitation de la base de données à la fin du fichier aof. En cas d'indisponibilité, la commande du fichier aof sera chargée et exécutée à nouveau pour atteindre l'objectif de récupération de l'état de la base de données. Il fournit trois Il existe deux types de méthodes de stockage d'intervalle: l'une consiste à écrire une fois dans une opération de commande, la seconde à écrire une fois toutes les secondes et la troisième à transférer le traitement de l'intervalle d'écriture à la gestion système. Écrivez une fois par seconde.
RDB est activé par défaut dans le fichier de configuration de redis et AOF est désactivé par défaut. Il existe trois façons d'exécuter la commande de sauvegarde par défaut dans le fichier de configuration de Redis.
save 900 1 --------------- En 900S, la base de données a été modifiée au moins une fois
save 300 10 -------------- En 300S, corriger La base de données a été modifiée au moins 10 fois
enregistrer 60 10000 ------------ En 60S, la base de données a été modifiée au moins 10000 fois
Panne, pénétration, avalanche et solutions de scénarios commerciaux pouvant survenir dans Redis haute concurrence
panne:
Si une touche d'accès rapide (comme une recherche rapide sur Weibo) a 10 000 requêtes par seconde, l'accès est très fréquent et elle est dans un état de forte concurrence. Si la validité de cette clé est soudainement invalidée, alors à ce moment, 10 000 fois par seconde La requête sera frappée directement sur la base de données. De toute évidence, la base de données ne peut pas résister à un tel accès à haute fréquence, qui va tuer la base de données.
résoudre:
Définissez les données du hotspot pour qu'elles n'expirent jamais ou implémentez un verrou d'exclusion mutuelle, verrouillez -> attendez que la machine de cache cache les données accédées pour la première fois -> libérez le verrou, de sorte qu'un accès simultané élevé ultérieur aux mêmes données puisse aller directement Les données sont extraites du cache et renvoyées.
pénétrer:
En supposant qu'il y a 10000 requêtes par seconde, dont 8000 requêtes sont envoyées par l'attaquant, aucun identifiant de ce type ne peut être trouvé dans le cache et la base de données (vous pouvez supposer que l'identifiant est un nombre négatif), dans ce cas également Va tuer la base de données
résoudre:
Tant que la clé qui n'est pas trouvée dans le cache ou la base de données pour la première fois, définissez la valeur correspondante sur null et écrivez-la dans le cache, de sorte que même s'il y a 7999 requêtes par la suite, null puisse être retourné directement au lieu de chaque fois Besoin de rechercher dans la base de données
avalanche:
S'il y a 10000 requêtes par seconde et que la machine de cache peut gérer jusqu'à 8000 requêtes par seconde, il n'y aura évidemment pas de problème, mais si la machine de cache tombe soudainement en panne, ces 8000 requêtes seront directement ajoutées. Sur la base de données, la base de données ne pourra inévitablement pas la supporter. En théorie, elle appellera d'abord la police puis raccrochera. En pratique, elle sera plus susceptible de raccrocher directement.
résoudre:
Au préalable: Redis est hautement disponible, séparation lecture-écriture, réplication maître-esclave + mode sentinelle, cluster redis, pour éviter un crash total.
Dans le cas où: cache local ehcache + limite de courant hystrix et rétrogradation pour empêcher MySQL d'être tué
Après l'événement: Redis persiste. Une fois redémarré, les données sont automatiquement chargées à partir du disque pour restaurer rapidement les données mises en cache
Redis transaction
open transaction
multi
execute command
exec in command queue
close transaction
discard
monitoring lock watch key
cancel monitoring unatch