Connexion
Connexion

Galerie de cartes mentales Apprentissage du cadre de connaissances sur la structure des données Redis

Apprentissage du cadre de connaissances sur la structure des données Redis

Étant donné qu'il existe de nombreux types de données Redis et que différents types de données ont les mêmes métadonnées à enregistrer, Redis utilisera une structure RedisObject pour enregistrer uniformément ces métadonnées. Lors de l'enregistrement du type Long, le pointeur RedisObject est directement affecté à un entier.

Modifié à 2022-11-14 13:53:00

WSrx009v

Œuvres récentes Afficher plus d'œuvres>>

Apprentissage du cadre de connaissances sur la structure des données Redis

WSrx009v

Œuvres récentes Afficher plus d'œuvres>>

Recommandé pour vous
Contour

Rédis
- 8
WSrx009v
Rédis
- 9
WSrx009v

Apprentissage du cadre de connaissances sur la structure des données Redis

Problèmes de cohérence du cache

Mettez d'abord à jour la base de données, puis supprimez le cache

(1) Le cache vient d'expirer (2) Demander à A d'interroger la base de données et d'obtenir une ancienne valeur (3) Demander à B d'écrire la nouvelle valeur dans la base de données (4) Demander à B de supprimer le cache (5) Demander à A d'écrire l'ancienne valeur trouvée dans le cache

Des données sales se produiront comme ci-dessus

Mais seulement si 3 parmi 2 et 3 est plus rapide que 2, B supprimera d'abord le cache et A écrira le cache avec l'ancienne valeur.

En fait, l’écriture dans la base de données est beaucoup plus lente que la lecture, évitez donc le SQL lent.

Supprimez d'abord le cache, puis écrivez dans la base de données

(1) Éliminez d'abord le cache (2) Réécrivez la base de données (ces deux étapes sont les mêmes que précédemment) (3) Dormez pendant 1 seconde et éliminez à nouveau le cache

Utiliser la double suppression asynchrone

Opérations de base

Opérations courantes

Vérifiez le nombre et la longueur

Qu'il existe, contient, ajoute, augmente ou diminue la clé ou un certain champ sous la clé

Supprimer, supprimer l'emplacement spécifié, supprimer et obtenir

thème gratuit

type de données

Clé

Supprimer, exister, afficher, faire correspondre par modèle (les grandes collections auront des problèmes de performances),

Scan itère toutes les clés,

Trier la liste, définir

Migrer d'une instance Redis vers une autre instance Redis

Définir, annuler le délai d'expiration et obtenir le délai d'expiration restant de la clé

Comment Redis élimine les clés expirées Il existe deux manières d'expirer les clés Redis : passive et active. Lorsque certains clients tentent d'y accéder, la clé sera découverte et expirera activement. Bien entendu, cela ne suffit pas, car certaines clés expirées ne seront jamais accessibles. Ces clés devraient expirer de toute façon, donc un test aléatoire chronométré définit le délai d'expiration des clés. Toutes ces clés expirées seront supprimées de l’espace clé. Plus précisément, voici ce que Redis fait 10 fois par seconde : Testez 20 clés aléatoires pour la détection d’expiration associée. Supprimez toutes les clés expirées. Si plus de 25 % des clés expirent, répétez l'étape 1. Il s'agit d'un algorithme probabiliste trivial. L'hypothèse de base est que notre échantillon est le contrôle des clés, et nous continuons à répéter la détection d'expiration jusqu'à ce que le pourcentage de clés expirées soit inférieur à 25 %, ce qui signifie qu'à un moment donné, à un moment donné, à la plupart des clés expirées seront effacées.

Ensemble

Sdiff récupère les éléments qui n'existent pas dans l'ensemble SDiff a b est équivalent à a-b

Sdiff Store stocke la différence définie dans une clé

Trouver l'union de plusieurs ensembles, pouvant être stockés dans une clé

SInter prend l'intersection SInterStore écrit l'intersection dans une clé

Liste

Opération BLOCK, bloquant une valeur en tête et en queue de la file d'attente

Vous pouvez spécifier d'obtenir les valeurs de plusieurs files d'attente

Lorsque la file d'attente est vide, le client sera bloqué jusqu'à ce qu'il y ait une écriture. Vous pouvez spécifier un délai d'attente et renvoyer zéro après le délai d'attente.

Les opérations de blocage garantissent l’équité

Redis 2.4 et 2.6 sont différents Lorsque plusieurs valeurs sont écrites en même temps, comme a, b, c, le client dont la clé est bloquée recevra a en 2.4 et c en 2.6.

Après avoir supprimé la valeur du serveur, si le client raccroche avant que la valeur ne soit traitée, la valeur sera perdue. Le mécanisme de confirmation de message de RabbitMQ peut résoudre ce problème.

Vous pouvez utiliser l'opération de blocage de List combinée à des opérations atomiques d'autres types de données dans la même transaction pour fournir un comportement de blocage au client.

Est-il possible d’obtenir des verrous distribués équitablement ?

Semblable aux opérations fournies par List en Java, LTrim est ajouté pour intercepter les valeurs dans une certaine plage.

Supprimez le dernier élément de la liste et placez-le dans une autre liste

thème gratuit

collecte commandée

Vous pouvez effectuer des opérations de réduction sur l'union de plusieurs ensembles ordonnés, prenant en charge SUM, MIN et MAX.

Renvoie le classement d'une clé dans un ensemble ordonné

Vous pouvez obtenir une certaine plage de valeurs dans un ensemble ordonné ; vous pouvez également spécifier les scores minimum et maximum pour interroger l'ensemble dans cette plage en pages.

Itérer sur une collection

Transaction

montre

La commande WATCH peut surveiller une ou plusieurs clés. Une fois l'une des clés modifiée (ou supprimée), les transactions suivantes ne seront pas exécutées. La surveillance continue jusqu'à la commande EXEC. Tant que la valeur est modifiée avant l'exécution de l'exécution, la transaction ne sera pas exécutée. Cela équivaut à une vérification redis pendant l'exécution.

Étant donné que la fonction de la commande WATCH est uniquement d'empêcher l'exécution d'une transaction ultérieure lorsque la valeur de la clé surveillée est modifiée, elle ne peut pas garantir que d'autres clients ne modifieront pas la valeur de la clé. Par conséquent, en général, nous devons réexécuter la commande. Exécution EXEC après l’échec de la fonction entière. Garanti avec une boucle

Après l'exécution de la commande EXEC, la surveillance de toutes les clés sera annulée. Si vous ne souhaitez pas exécuter les commandes dans la transaction, vous pouvez également utiliser la commande UNWATCH pour annuler la surveillance. Dans certains scénarios commerciaux, après avoir observé, nous n'effectuons pas nécessairement d'opérations de transaction.

La commande Watch est une technologie de verrouillage optimiste. Tant que cette valeur de clé est modifiée, les modifications valides ultérieures ne prendront pas effet. Cette méthode peut généralement être utilisée pour réduire les conditions de concurrence. Lorsque exec renvoie une collection vide, l'opération est considérée comme un échec.

Exec exécute en fait toutes les instructions de la transaction et efface la commande watch.

La réponse de la commande Exec est un tableau cohérent avec l’ordre d’exécution de la commande.

Même si une ou plusieurs commandes de la transaction ne parviennent pas à s'exécuter, les autres commandes de la file d'attente des transactions continueront à être exécutées - Redis n'arrêtera pas d'exécuter les commandes de la transaction.

Avant que la transaction n'exécute EXEC, des erreurs peuvent se produire dans les commandes mises en file d'attente. Par exemple, la commande peut produire des erreurs de syntaxe (mauvais nombre de paramètres, mauvais noms de paramètres, etc. Dans ce cas, le client arrêtera d'exécuter la transaction

Toutes les commandes exécutées depuis le début de la commande Mutil jusqu'à la commande exec seront inscrites dans la file d'attente des transactions.

Hacher

Qu'il existe, ajouter, supprimer, obtenir toutes les clés, valeurs, itérer la collection de hachage

Incrémentez la valeur de hachage d'une clé. Si la clé n'existe pas, définissez-la sur 0, incrémentez la valeur.

thème gratuit

Pièges liés à la structure des données

Lorsque la taille de la chaîne doit être étendue, si elle est inférieure à 1 M, elle sera doublée. Si elle est supérieure à 1 M, elle ne sera étendue que de 1 M à chaque fois. La longueur maximale est de 512 M.

Si la valeur d'auto-incrémentation dépasse la valeur maximale, une erreur sera signalée.

Pour les structures de données de type conteneur, si le conteneur n'existe pas, créez-le ; si l'élément n'existe plus, supprimez le conteneur.

Verrouillage distribué

Solution à nœud unique (verrou non rouge)

Obtenir le verrouillage

hacher vers un nœud de cluster

S'il n'existe pas, définissez le chemin de verrouillage. Définissez le délai d'expiration.

Le verrouillage consiste à définir la valeur de l'ID client

Configurez un chien de garde et mettez à jour le verrou régulièrement. Cela peut être implémenté à l'aide d'une file d'attente différée.

Si le verrou n’est pas acquis, pensez à le bloquer et à attendre l’acquisition.

Ouvrir

Si le délai d'expiration n'est pas défini, cela entraînera un problème de blocage.

a) Une fois qu'un commutateur maître-esclave se produit dans Redis, certains verrous peuvent être perdus.

Comparer avec zk

Le verrouillage distribué mis en œuvre par Zookeeper présente en réalité un inconvénient, c'est-à-dire que les performances peuvent ne pas être aussi élevées que celles du service de cache. Car à chaque fois pendant le processus de création et de libération d'un verrou, des nœuds transitoires doivent être créés et détruits dynamiquement pour implémenter la fonction de verrouillage. La création et la suppression de nœuds dans ZK ne peuvent être effectuées que via le serveur Leader, et les données ne sont alors pas partagées avec toutes les machines Follower. Problèmes de concurrence, il peut y avoir une instabilité du réseau, la connexion de session entre le client et le cluster ZK est interrompue, le cluster zk pense que le client est en panne et supprimera le nœud temporaire. À ce moment, d'autres clients peuvent obtenir le verrou distribué. .

Redis est difficile à atteindre l'équité

rouge

Dans la version distribuée de l’algorithme, nous supposons que nous disposons de N hôtes Redis. Les nœuds sont complètement indépendants, nous n'utilisons donc pas de réplication ou tout autre système de coordination implicite. Nous avons décrit comment acquérir et libérer des verrous en toute sécurité au sein d'une seule instance. Nous tenons pour acquis que l’algorithme utilisera cette méthode pour acquérir et libérer les verrous en une seule instance. Dans notre exemple, nous définissons N = 5, ce qui est une valeur raisonnable, nous devons donc exécuter 5 serveurs maîtres Redis sur différents ordinateurs ou machines virtuelles pour garantir qu'ils échouent de manière essentiellement indépendante. Pour acquérir le verrou, le client effectue les opérations suivantes : 1. Il obtient l’heure actuelle en millisecondes. 2. Il tente d'acquérir le verrou dans toutes les N instances dans l'ordre, en utilisant le même nom de clé et la même valeur aléatoire dans toutes les instances. Au cours de l'étape 2, lorsque le verrou est défini dans chaque instance, le client utilise un petit délai d'attente par rapport au temps total de libération automatique du verrou pour l'acquérir. Par exemple, si le temps de libération automatique est de 10 secondes, le délai d'attente peut être compris entre 5 et 50 ms. Cela évite que les clients restent bloqués pendant de longues périodes, essayant et échouant de parler à un nœud Redis : si une instance n'est pas disponible, nous devons essayer de parler à l'instance suivante le plus rapidement possible. 3. Le client calcule le temps nécessaire pour acquérir le verrou en soustrayant l'horodatage obtenu à l'étape 1 de l'heure actuelle. Un verrou est considéré comme acquis si et seulement si le client est capable d'acquérir le verrou dans une majorité de cas (au moins 3) et que le temps total écoulé pour acquérir le verrou est inférieur à la durée de validité du verrou. 4. Si un verrou est acquis, sa durée de validité est considérée comme étant la durée de validité initiale moins le temps écoulé, tel que calculé à l'étape 3. 5. Si le client ne parvient pas à acquérir le verrou pour une raison quelconque (impossibilité de verrouiller N/2 1 instances ou durée de validité négative), il tentera de déverrouiller toutes les instances (même s'il pense ne pas pouvoir verrouiller).

Lorsqu'un nœud est raccroché, il n'y a aucun risque que le verrou soit préempté.

cache

Invalide

Définir une valeur aléatoire pour le temps de défaillance afin d'éviter une défaillance collective

Implémentation de la structure des données

Scénarios d'application

zset

Enregistrer la liste des identifiants de publication des utilisateurs.

Enregistrer la liste d'identification des publications de la liste de favoris globale, la liste de favoris des catégories.

Utilisé pour enregistrer un à plusieurs, et la fête avec plusieurs ne peut pas être strictement répétée.

Enregistrez une certaine collection, qui peut être liée à l'utilisateur ou à l'ensemble du système.

hacher

Enregistrez le nombre de likes, de commentaires et de clics sur une publication.

Enregistrez le titre du message, le résumé, l'auteur, les informations de couverture, etc.

Mettre en cache le contenu des publications chaudes récentes (le contenu de la publication est très volumineux et ne convient pas à la récupération à partir de la base de données)

liste

Enregistrez la liste des articles associés à la publication. Recommandez les publications associées en fonction du contenu.

image bitmap

Utilisé comme tableau booléen ou tableau de bits personnalisé, principalement pour économiser de la mémoire

HyperLogLog

Utilisé pour calculer grossièrement les valeurs statistiques après déduplication.

Par exemple, l'UV du site Web doit filtrer les visites répétées

Vous pouvez uniquement additionner et obtenir le nombre total, mais vous ne pouvez pas savoir si une certaine valeur existe ou tous les éléments.

filtre de floraison

Utilisé pour supprimer les doublons. Obtenez si un élément existe dans la liste.

Si ça existe, ça n’existe pas forcément vraiment Si ça n'existe pas, ça n'existe certainement pas

Pensez à recommander des ressources non visitées aux utilisateurs

Pensez à ne pas réutiliser les ressources plusieurs fois.

Un certain taux d'échec doit être toléré, c'est-à-dire que la ressource n'est pas accessible, mais elle est considérée comme ayant été accédée.

Utilisez plusieurs algorithmes de hachage et définissez les bits du mappage de clé sur 1.

Si ça n’existe pas, ça n’existe définitivement pas !!!!

Il n'y a que des commandes d'ajout et d'existence (plusieurs peuvent être vérifiées)

Vous pouvez utiliser les paramètres initiaux pour définir le filtre error_rate est le taux d'erreur. Plus la valeur est faible, plus la capacité est grande. initial_size est le montant total estimé. Le montant total doit être défini en fonction du scénario réel.

Cellule Redis

Si le projet n'est pas volumineux et que le coût de maintenance n'est pas élevé, vous pouvez utiliser redsi-cell directement. Sinon, vous pouvez envisager un contrôle précis de chaque nœud de service pour limiter le flux et le mettre en œuvre avec la stratégie d'équilibrage de charge correspondante.

Utilisez zset et score pour encercler la fenêtre temporelle et compter le nombre de fois où le même comportement se produit pour le même utilisateur dans la fenêtre temporelle. Si le nombre de limites actuelles est trop grand, il peut ne pas être applicable, par exemple 1 000 fois par seconde. .

CL.TEST GÉNÉRATEUR 100 400 60 3

testez la capacité de la clé 100 (concurrence maximale) jusqu'à 400 fois en 60 secondes. Cette fois, 3 capacités sont demandées.

1 : Si c'est réussi, 0 : Succès, 1 : Rejet 2 : La capacité du compartiment à jetons, la taille est la valeur initiale 1 3 : Jetons disponibles dans le compartiment de jetons actuel 4 : Si la demande est rejetée, cette valeur indique le temps qu'il faudra avant que le jeton soit réajouté au compartiment de l'entonnoir. Unité : secondes, qui peut être utilisée comme temps de nouvelle tentative. 5 : Indique combien de temps il faudra pour que les jetons dans le compartiment à jetons soient pleins.

algorithme d'entonnoir

structure de données spéciale

Liste chaînée compressée

Il est composé de listes chaînées ou de tableaux compressés, afin d'éviter la surcharge de mémoire supplémentaire des listes chaînées ordinaires.

Une liste doublement chaînée conçue pour économiser autant de mémoire que possible

Stocker une chaîne ou un entier

Économisez de la mémoire dans les détails, en utilisant un codage à longueur variable pour le stockage des valeurs

Chaque élément aura un nombre distinct de chiffres pour marquer la longueur des données et le type de l'élément.

Implémentation de structures de données sous-jacentes de hachage, liste et zset

Caractéristiques

1) La représentation interne est une matrice de mémoire continue dans laquelle les données sont disposées de manière compacte.

2) Vous pouvez simuler une structure de liste doublement chaînée et entrer et retirer de la file d'attente avec une complexité temporelle O(1).

3) La nouvelle opération de suppression implique une réallocation ou une libération de mémoire, ce qui augmente la complexité de l'opération.

4) Les opérations de lecture et d'écriture impliquent des mouvements de pointeur complexes, et la complexité temporelle dans le pire des cas est O(n2).

5) Convient pour stocker de petits objets et des données de longueur limitée.

1) Lorsque vous utilisez ziplist pour des scénarios avec des exigences de performances élevées, il est recommandé que la longueur ne dépasse pas 1 000 et que la taille de chaque élément soit contrôlée dans les 512 octets.

table de saut

La liste de saut prend en charge la recherche moyenne O(logN) et la recherche de complexité O(N) dans le pire des cas.

Pourquoi ne pas utiliser des arbres ou des arbres équilibrés au lieu de tables de saut ?

L'implémentation de la table de sauts est très simple et peut atteindre le niveau O(logN).

liste de liens rapide

La liste chaînée compressée est liée à l'aide de pointeurs pour devenir une liste chaînée

La valeur par défaut de chaque liste zip est 8k (configurable).

Opération et maintenance

moniteur

2) Utilisez la commande info Commandstats pour obtenir la durée moyenne des commandes, y compris le nombre d'appels pour chaque commande. , le temps total pris, le temps moyen pris, en microsecondes.

Maître d'esclave

La fonction de réplication de Redis est divisée en deux opérations : synchronisation (sync) et propagation de commande (propagation de commande) :

Les opérations de synchronisation permettent de récupérer l'état de la base de données depuis le serveur Mise à jour de l'état actuel de la base de données du serveur principal ;

L'opération de propagation de commande permet de modifier l'état de la base de données sur le serveur principal. Lorsque l'état de la base de données du serveur maître-esclave est incohérent, laissez le serveur maître-esclave La base de données du serveur retrouve un état cohérent.

Séparation en lecture et en écriture

La séparation de la lecture et de l'écriture convient aux accès volumineux (si grands qu'une seule machine Redis semble très lente), et l'opération d'écriture est beaucoup plus petite que l'opération de lecture.

Si le nombre de requêtes de lecture dépasse largement le nombre de requêtes d'écriture, le coût de copie des données du cluster sera bien inférieur au coût de la requête de lecture. Dans le même temps, si nous pouvons accepter dans une certaine mesure l'incohérence des données, nous pouvons séparer la lecture et l'écriture.

cluster redis

caractéristique

1. Tous les nœuds Redis sont interconnectés les uns aux autres (mécanisme PING-PONG) et un protocole binaire est utilisé en interne pour optimiser la vitesse de transmission et la bande passante.

2. La panne d'un nœud ne prend effet que lorsque plus de la moitié des nœuds du cluster détectent des pannes.

3. Le client est directement connecté au nœud Redis, sans avoir besoin d'une couche proxy intermédiaire. Le client n'a pas besoin de se connecter à tous les nœuds du cluster, il suffit de se connecter à n'importe quel nœud disponible du cluster.

4. redis-cluster mappe tous les nœuds physiques sur l'emplacement [0-16383] (pas nécessairement uniformément réparti) et le cluster est responsable du maintien de la valeur du nœud <-> emplacement <->.

Chaque nœud Redis doit exécuter une commande et déclarer l'emplacement dont il est responsable.

le cluster ajoute des emplacements {slot_index1} {slot_index 2} {slot_index 3}

5. Le cluster Redis est pré-divisé en 16384 compartiments Lorsqu'une clé-valeur doit être placée dans le cluster Redis, il est décidé en fonction de la valeur du CRC16(key) mod 16384 dans quel compartiment une clé doit être placée.

Chaque instance Redis est consciente de l'existence d'autres nœuds

Une forte cohérence ne peut pas être garantie

1. Votre client écrit sur le nœud du serveur principal B 2. Le nœud du serveur principal B répond à votre client pour confirmer. 3. Le nœud du serveur maître B propage l'écriture vers ses serveurs esclaves B1, B2 et B3.

Si après l'étape 2, aucune donnée n'est envoyée depuis le serveur esclave et que B raccroche, la clé sera perdue (la clé sera définitivement perdue lors de la panne)

tolérance aux pannes

Le processus d'élection implique la participation de tous les maîtres du cluster. Si plus de la moitié des nœuds maîtres communiquent avec le nœud défaillant pendant plus de (cluster-node-timeout), le nœud est considéré comme défectueux et l'opération de basculement est automatiquement effectuée. déclenché.

(2) : Quand l'ensemble du cluster devient-il indisponible (cluster_state:fail) ? a : Si un maître du cluster meurt et que le maître actuel n'a pas d'esclave, le cluster entre dans l'état d'échec, ce qui peut également être compris comme entrant dans l'état d'échec lorsque le mappage des emplacements du cluster [0-16383] n'est pas terminé. b : Si plus de la moitié des maîtres du cluster meurent, qu'il y ait ou non un cluster esclave entrant en état d'échec.

Lorsque le cluster est indisponible, toutes les opérations sur le cluster sont indisponibles et une erreur ((erreur) CLUSTERDOWN Le cluster est en panne) est reçue.

basculement

1. Tous les nœuds esclaves du nœud maître hors ligne seront élus pour élire un nouveau nœud maître. 2. Le nœud esclave sélectionné exécutera la commande slave no one et deviendra le nouveau nœud maître. 3. Le nouveau nœud maître révoquera toutes les attributions d'emplacements au nœud maître hors ligne et s'attribuera ces emplacements. 4. Le nouveau nœud maître diffuse un message pong au cluster. Ce message pong permet aux autres nœuds du cluster de savoir immédiatement que le nœud est passé d'un nœud esclave à un nœud maître et que le nœud maître a pris le contrôle du serveur. qui était à l'origine hors ligne. L'emplacement géré par le nœud. 5. Le nouveau nœud maître commence à accepter les demandes de commandes liées à l'emplacement qu'il est responsable du traitement et l'opération de basculement est terminée.

élection maître-esclave

1. Lorsque le nœud esclave constate que le nœud maître qu'il réplique est hors ligne, le nœud esclave (il peut y avoir plusieurs nœuds esclaves faisant des demandes ici) diffusera un message cluster_type_failover_auth_request au cluster, nécessitant des droits de vote (responsable du traitement des emplacements). le nœud maître vote pour ce nœud. 2. Le nœud maître qui reçoit le message cluster_type_failover_auth_request jugera s'il est d'accord avec le nœud esclave pour devenir le nouveau nœud maître en fonction de ses propres conditions (l'époque actuelle du nœud votant initiateur n'est pas inférieure à l'époque actuelle du nœud votant ). S'il est d'accord, il renverra un message cluster_type_failover_auth_ack. 3. Lorsque le message cluster_type_failover_auth_ack est reçu du nœud, le nombre de votes sera augmenté de 1. 4. Si les votes d'un nœud esclave sont supérieurs ou égaux à la moitié des nœuds maîtres du cluster (supérieurs ou égaux à N/2 1), ce nœud deviendra le nouveau nœud maître. Si aucun nœud esclave ne reçoit suffisamment de votes au cours d'un cycle de configuration, le cluster entrera dans un nouveau cycle de configuration et des élections auront lieu ici jusqu'à ce qu'un nouveau nœud maître soit élu.

Tous les nœuds esclaves peuvent demander leur avis pour savoir s'ils peuvent devenir maîtres (ceux qui votent ne voteront que pour leurs propres nœuds plus grands), et plus de la moitié d'entre eux peuvent être (n 1)/2

Peut-être que je ne peux pas choisir

limites

1. Actuellement, seules les opérations par lots de clés sur le même emplacement sont prises en charge ; 2. Actuellement, seules les transactions clés sur le même emplacement sont prises en charge ; 3. Seule la base de données 0 peut être utilisée (chaque instance Redis dispose de 16 bases de données, qui peuvent être commutées via la commande select {index}) ; 4. Une clé volumineuse (telle qu'un hachage, une liste) ne peut pas être mappée à différents nœuds ; 5. Actuellement, la réplication maître-esclave du cluster ne prend en charge qu'un seul niveau et ne prend pas en charge la structure arborescente imbriquée ;

Lors de l'expansion

étape

1. Envoyer au nœud cible cluster setslot {slot_index} importation {source_node_id} 2. Envoyer au nœud source cluster setslot {slot_index} migration {target_node_id} 3. Exécution de la boucle du nœud source cluster getkeysinslot {slot_index} {count(nombre de clés)} 4. Le nœud source exécute et migre la clé vers le nœud cible via le pipeline. migrer {target_ip} {target_port} "" 0 {timeout} clés {key1} {key2} {key3} 5. Répétez les étapes 3 et 4 6. Envoyez des notifications à tous les nœuds maîtres du cluster cluster setslot {slot_index} nœud {target_nodeid}

Chaque nœud connaît le nœud du cluster correspondant à chaque emplacement.

Lorsque le nœud reçoit la demande de commande, il demande s'il peut la gérer lui-même. Si tel est le cas, il la gère. Dans le cas contraire, il renvoie une erreur de déplacement contenant l'adresse IP et le numéro de port corrects du nœud et les renvoie. client pour le guider dans son exécution. Et chaque opération ultérieure du client. Une fois la clé exécutée, elle ira au nœud fourni par l'erreur déplacée.

Codis

Couche d'accès : la méthode d'accès peut être VIP ou appeler jodis via du code java, puis se connecter et appeler différentes adresses proxy codis pour obtenir des fonctions LVS et HA à haute disponibilité.

Couche proxy : Ensuite, la couche intermédiaire utilise codis-proxy et zookeeper pour traiter la direction et la distribution des données grâce à l'algorithme crc32, les clés sont réparties uniformément dans un certain emplacement de différents redis pour obtenir une répartition similaire à raid0, dans l'ancienne version. de codis, les emplacements doivent être alloués manuellement après codis3.2, les emplacements seront alloués automatiquement, ce qui est assez pratique.

Couche de données : Enfin, codis-proxy stocke les données sur le véritable serveur principal redis-server. Étant donné que l'auteur de codis, Huang Dongxu, attache une grande importance à la cohérence des données et n'autorise pas les incohérences des données causées par des retards de données, l'architecture n'a pas été conçue. considéré depuis le début, la lecture et l'écriture maître-esclave sont séparées. Le serveur esclave n'est utilisé que comme architecture redondante pour le basculement, et zookeeper appelle redis-sentinel pour implémenter la fonction de basculement.

Dans Codis, Codis divisera toutes les clés en 1024 emplacements. Ces 1024 emplacements correspondent au cluster Redis. Dans Codis, la relation de mappage entre ces 1024 emplacements et l'instance Redis sera conservée en mémoire. Cet emplacement est configurable et peut être réglé sur 2048 ou 4096. Cela dépend du nombre de nœuds dont dispose votre Redis. S'il y en a trop, vous pouvez définir plus d'emplacements.

Lorsque le tableau de bord Codis de Codis modifie les informations sur l'emplacement, d'autres nœuds Codis surveillent les modifications de l'emplacement ZooKeeper et les synchronisent dans le temps. Comme le montre l'image :

zk est responsable de la synchronisation des informations sur les emplacements.

File d'attente de priorité

ensemble trié

liste

Utilisez plusieurs files d'attente pour implémenter des files d'attente prioritaires. Différentes tâches prioritaires entrent dans différentes files d'attente.

Dans le même temps, lorsque les consommateurs récupèrent des données dans la file d'attente, ils prennent en charge la récupération des données dans plusieurs files d'attente, avec un ordre de priorité.

bloqué

Démarrer plusieurs consommateurs signifie démarrer plusieurs clients pour récupérer des données.

file d'attente des messages

pubsub

utiliser

Les abonnés peuvent s'abonner à un, plusieurs sujets d'abonnement correspondants

L'éditeur publie un certain sujet et valorise

Les sujets publiés seront immédiatement transmis aux consommateurs qui s'abonnent au sujet. S'il n'y a pas de consommateurs, le message sera ignoré.

risque

Il y aura un risque de perte de messages (lorsque la machine est en panne, le réseau est déconnecté, ou le réseau est interrompu et les messages sont perdus)

En raison de cette fonctionnalité, un simple pubsub court le risque de perdre des réponses.

La fiabilité des données ne peut être garantie

Il n'y a aucune garantie qu'au moins une fois

L’expansion n’est pas flexible et il n’existe aucun moyen d’accélérer la consommation en ajoutant davantage de consommateurs.

Vous pouvez utiliser plusieurs chaînes et écouter plusieurs fois.

liste

1. Lorsqu'il n'y a aucun élément dans la liste donnée à afficher, la connexion sera bloquée par la commande BRPOP jusqu'à ce que le délai d'attente expire ou qu'un élément pouvant être affiché soit trouvé. 2. Lorsque plusieurs paramètres clés sont donnés, chaque liste est vérifiée dans l'ordre en fonction de la clé du paramètre et l'élément de queue de la première liste non vide apparaît. De plus, BRPOP se comporte de la même manière que BLPOP, à l'exception de la position de l'élément contextuel.

S'il n'y a aucune tâche dans la liste, la connexion sera bloquée Il existe un délai d'attente pour le blocage de la connexion. Lorsque le délai d'attente est défini sur 0, vous pouvez attendre sans fil jusqu'à ce qu'un message apparaisse.

En utilisant pubsub, vous pouvez également informer les consommateurs qu'ils peuvent consommer à partir de la liste.

Il convient à l'abonnement et à la publication entre deux entreprises entre A et B. C'est plus difficile lorsque plusieurs secteurs d'activité impliquent des consommateurs différents.

implémentation de l'accusé de réception

Conservez deux files d'attente : la file d'attente en attente et la table d'exécution (table de hachage).

les travailleurs sont définis comme ThreadPool. Après avoir été mis en file d'attente par la file d'attente en attente, les travailleurs allouent un thread (un seul travailleur) pour traiter le message - ajoutent un horodatage actuel et un nom de thread actuel au message cible, l'écrivent dans la table de tâches, puis le travailleur consomme le message après. achèvement Effacez vous-même les informations du tableau des tâches.

Activez une tâche planifiée, analysez la file d'attente d'exécution à intervalles réguliers et vérifiez l'horodatage de chaque élément. En cas d'expiration, le ThreadPoolExecutor du travailleur vérifiera si le thread existe. S'il existe, l'exécution de la tâche en cours sera annulée et la transaction. sera annulé. Enfin, sortez la tâche de la file d'attente en cours et remettez-la dans la file d'attente en attente.

Vous pouvez utiliser zset pour le tri.

Évitez la surutilisation de Redis. Utilisez Redis uniquement pour faire les choses pour lesquelles vous êtes le meilleur et faites les choses pour lesquelles vous n'êtes pas bon. Plus vous en faites, plus vous en découvrirez. Plus il y a d’embûches, plus il est difficile d’abandonner au final. Une mauvaise conception au début entraîne un taux d’échec élevé dans la phase ultérieure, une mauvaise stabilité et des coûts de transformation élevés, etc. Rabbitmq n'est pas très compliqué. L'exploitation et la maintenance sont également très simples et peuvent être mélangées avec le système métier.