Kenji trouver rapidement le travail, et d' organiser leurs propres questions peu d'entrevue commune ...
Références: « Le développement Redis et de l' exploitation et de l' entretien. »
profil 1.Redis
NoSQL Redis est une base de données basée sur une clé (clé-valeur) en utilisant une architecture mono-thread, et le modèle de multiplexage I / O pour mettre en oeuvre le service de base de données de mémoire à haute performance. L'avantage est la vitesse, sur la base de la structure de données de paires de valeurs de clé des serveurs, riche en fonctionnalités, simple et stable, client multi-langue, la persistance, la réplication maître-esclave, le support pour la haute disponibilité et distribué. Redis peut faire la mise en cache, le système de classement, les applications de compteurs, les réseaux sociaux, les systèmes de messages en file d'attente.
2,5 types de structures de données
- Chaîne: string, integer ou float, pour le stockage kv plus simple;
- Liste: listes, ou peuvent être pressés des deux extrémités de l'élément contextuel, adapté pour obtenir une liste de fans similaire, les commentaires de cet article les données et similaires;
- Hash: liste non ordonnée contient des paires de valeurs clés;
- Set: un ensemble non ordonné peut être réalisé intersection, l'union, la différence;
- Zset: ensemble ordonné, version améliorée de l'ensemble, et ajoute des paramètres de partition seront triés automatiquement en fonction de la valeur du score.
3. endurance
Fonction persistance éviter efficacement la perte de données causée par le processus de problèmes de sevrage lorsque le prochain redémarrage fichier persistant avant de pouvoir utiliser la récupération de données. Redis soutient et RDB deux types de AOF mécanisme de persistance.
RDB persistance est un instantané des données de processus actuel est enregistré sur le disque dur du processus, en fonction de certaines données à mémoire de temps enregistrées sur le disque dur sous la forme d'un instantané du fichier de données généré pour le dump.rdb correspondant. RDB est un fichier binaire compact comprimé, au nom de l' instantané des données Redis à un moment qui convient à la quantité de scénarios de sauvegarde et de réplication. Redis RDB de charge pour récupérer les données beaucoup plus rapidement que l' AOF. Mais RBD ne convient pas à la persistance à temps réel.
AOF a persisté de manière indépendante pour enregistrer chaque écriture de journal explicitement, puis ré-exécuter les commandes dans le fichier afin d'obtenir l' AOF redémarrage de récupération de données. Le rôle principal est de résoudre la persistance des données en temps réel.
4. Transaction
Redis offre une capacité simple transaction, un ensemble de commandes à exécuter entre mutil et mis en place deux commande exec. représentant Open mutil de la transaction, la transaction pour le compte de la fin de la commande Exec est réalisée entre ceux - ci afin atomique.
commande Watch est un verrouillage optimiste pour surveiller une ou plusieurs clés, une fois l' une des clés qui ont été modifiées, après la transaction ne sera pas exécutée.
Jeter commande pour effacer la file d' attente des transactions, renoncer à l' application de la branche.
5. Copier
Le montant total de la réplication: Habituellement utilisé pour les scènes principales de copie, il maîtrisera noeud à l' ensemble des données d'un noeud de transmission, lorsque la quantité de données est importante, le nœud maître et le réseau serait en effet les coûts.
Partie réplication: données primaires pour le traitement de perte de Glitch réseau Yin d'autres causes du scénario de réplication, lorsque le nœud du nœud maître à cet égard, si les conditions le permettent, le nœud maître au noeud esclave remplacement des données manquantes. Parce que le remplacement des données est beaucoup moins que la totalité du montant de la copie, vous pouvez éviter les frais généraux de la totalité du montant est trop grand pour copier.
6. Sentinel
Lorsque le nœud primaire échoue, Redis détection de défaut Sentinel et peut transférer automatiquement et informe le côté de l' application, ce qui permet la vraie haute disponibilité.
Redis Sentinel est une architecture distribuée, qui comprend un certain nombre de noeuds Redis Sentinel et des noeuds de données, chaque nœud serait de nœud de données Sentinel Sentinel et la surveillance des autres nœuds, et quand il trouve un nœud est injoignable, fera underscore identifie le nœud. Si le nœud maître est identifié, il Sentinel noeuds et autres « consultations », alors que la plupart des noeuds Sentinel sont considérés comme le nœud principal injoignable, ils éliraient un nœud Sentinel pour terminer le travail de basculement automatique, et il sera la modification en temps réel Redis côté application.
Redis Sentinel comprend:
Surveillance : détection noeud Sentinel noeud de données Redis périodiquement, que le reste du noeud Sentinel up;
notification : Résultats de noeud Sentinel basculera à notifier au côté application, le
basculement du noeud maître : réaliser une promotion des principaux noeuds et le noeud maintenir la relation maître-esclave ultérieur correct;
configuration fournies par : dans la structure Sentinel Redis, au moment où le client initie la connexion est définie noeud Sentinel, le noeud maître à partir de laquelle pour obtenir des informations.
7. Cluster
fentes de hachage Cluster Redis 16384, 16384 pour chaque touche de la somme de contrôle CRC16 modulo pour déterminer quel emplacement placé, chaque noeud de la grappe est responsable d'une partie de la valeur de hachage de la fente. Alors que la première copie du modèle de cluster, chaque noeud a une copie de la n-1.
programme de cluster CODIS est actuellement le plus utilisé.
8. problème de la mise en cache
préchauffage du cache: Avant de démarrer le système à l' avance pour charger des données directement liées au système tampon de cache pour éviter la demande de l'utilisateur d'interroger la base de données, puis le cache de données. Les utilisateurs d'interroger les données de cache directement été préalablement préchauffé.
Cache Avalanche: instant les données expirées est trop grand, ce qui entraîne une pression sur le serveur de base de données.
la rupture du cache: instant de données périmées forte fièvre, l' accès à une grande quantité de données, après rate Redis, a lancé un grand nombre d'accès de base de données pour les mêmes données, ce qui entraîne une pression sur le serveur de données.
la pénétration du cache: cache et base de données ne sont pas des données, ce qui provoque toutes les demandes sont tombées sur la base de données, résultant en un temps résister à un grand nombre de demandes de base de données et rebondissent.
9. La politique de collecte des ordures
Redis mécanismes de récupération de mémoire principalement dans les deux façons suivantes:
soit supprimer le délai d'expiration de l' objet clé,
limite d'utilisation de la mémoire est atteinte pour déclencher une stratégie de contrôle de débordement de mémoire sur MaxMemory.
1. Supprimer l' objet clé expiré
(1) Supprimer Inert: pour, lorsque le client avec la propriété clé de délai d' attente de lecture, si le délai d'expiration a dépassé la clé de jeu supprimera le fonctionnement et le retour.
(2) la suppression de tâches planifiées: Redis internes maintiennent une tâche régulière, la valeur par défaut courir 10 fois par seconde. tâche de synchronisation de suppression logique de clé expirée utilise un algorithme adaptatif, en fonction de la proportion de clé expirée, rapide et le mode vitesse lente reprise avec la touche.
2. Mémoire pleine stratégie de contrôle
(1) noeviction: stratégie par défaut, ne supprime pas les données, rejeter toutes les opérations d'écriture et est retourné au client une commande OOM de message d'erreur (erreur) pas autorisée lorsque la mémoire utilisée, mais cette fois la réponse Redis à une opération de lecture.
(2)-lru volatile: L'algorithme LRU suppression d' une propriété de délai d' attente (le VALABLE) jusqu'à ce que de libérer
suffisamment d' espace a été fait. Si aucun objet clé peuvent être supprimés, replier la stratégie de noeviction.
(3) AllKeys-LRU: touche Suppr selon l'algorithme LRU, quelle que soit l'ensemble des données de la propriété de délai d'attente n'a pas, jusqu'à présent assez pour libérer de l' espace.
(4) AllKeys aléatoire: supprimer toutes les clés aléatoires jusqu'à ce libérer de l' espace suffisant.
(5) aléatoire volatile: suppression de la clé expiré aléatoire jusqu'à libérer suffisamment d' espace.
(6) volatile ttl: ttl en fonction des attributs clés de l'objet, supprimer récemment expirer les données. Sinon,
replier stratégie noeviction.
