Comment analyser les points de connaissance Redis-Redis-php.cn

C'est une structure de données plutôt qu'un type

De nombreux articles diront que Redis prend en charge 5 types de données couramment utilisés. C'est en fait une grande ambiguïté. Toutes les données binaires stockées dans Redis sont en fait un tableau d'octets (byte[]). Ces données d'octets n'ont aucun type de données. Elles ne peuvent être transformées en chaîne, en entier ou en objet qu'après les avoir décodées dans un format raisonnable. avoir un type de données.

Cela doit être rappelé. Ainsi, tout ce qui peut être converti en tableau d'octets (byte[]) peut être stocké dans Redis. Tant qu'il est converti en tableau d'octets, qu'il s'agisse d'une chaîne, d'un nombre, d'un objet, d'une image, d'un son, d'une vidéo ou d'un fichier, il peut être traité.

Donc, String dans redis ne fait pas référence à une chaîne. Elle représente en fait la structure de données la plus simple, c'est-à-dire qu'une clé ne peut correspondre qu'à une seule valeur. La clé et la valeur ici sont toutes deux des tableaux d'octets, mais la clé est généralement un tableau d'octets converti à partir d'une chaîne et la valeur est déterminée en fonction des besoins réels.

Dans certaines circonstances, il existe également certaines exigences en matière de valeur. Par exemple, si une opération d'auto-incrémentation ou d'auto-décrémentation doit être effectuée, le tableau d'octets correspondant à la valeur doit pouvoir être décodé en un nombre, sinon une erreur sera signalée.

Donc, la structure des données de List signifie en fait qu'une clé peut correspondre à plusieurs valeurs, que les valeurs sont dans l'ordre et que les valeurs peuvent être répétées.

Set est une structure de données qui signifie qu'une clé peut correspondre à plusieurs valeurs, qu'il n'y a pas d'ordre entre les valeurs et que les valeurs ne peuvent pas être répétées.

Le hachage est une structure de données qui signifie qu'une clé peut correspondre à plusieurs paires clé-valeur. À l'heure actuelle, l'ordre entre ces paires clé-valeur a généralement peu de sens. Il s'agit d'une structure de données accessible en fonction de la sémantique du nom. et Sémantique non positionnelle.

Sorted Set est une structure de données qui signifie qu'une clé peut correspondre à plusieurs valeurs. Les valeurs sont triées par taille et les valeurs ne peuvent pas être répétées. Chaque valeur est associée à un nombre à virgule flottante appelé score. Les règles de tri des éléments sont les suivantes : trier d'abord par score, puis par valeur.

Je pense que vous avez maintenant une compréhension plus claire de ces cinq structures de données et que leurs commandes correspondantes ne sont qu'un petit cas pour vous.

Problèmes et solutions apportés par les clusters

Les avantages apportés par les clusters sont évidents, notamment une capacité accrue, des capacités de traitement améliorées et une expansion et une contraction dynamiques selon les besoins. Mais cela introduira également de nouveaux problèmes, au moins les deux suivants.

L'allocation de données comprend la détermination du nœud où les données sont stockées pendant le stockage et la détermination du nœud où les données sont interrogées lors de la récupération. La seconde est le mouvement des données : lorsque le cluster se développe et qu'un nouveau nœud est ajouté, d'où viennent les données sur le nœud ; lorsque le cluster se rétrécit et qu'un nœud est supprimé, où vont les données sur le nœud.

Les deux problèmes ci-dessus ont une chose en commun : comment décrire et stocker la relation de mappage entre les données et les nœuds. L'évolution du problème réside dans la nécessité d'établir une association entre chaque clé et tous les nœuds du cluster, car l'emplacement des données est déterminé par la clé.

Les nœuds du cluster sont relativement fixes et peu nombreux, bien qu'il y ait des nœuds ajoutés et des nœuds supprimés. Dans un cluster, les clés stockées sont très nombreuses, complètement aléatoires, irrégulières, imprévisibles et pour la plupart triviales.

C'est comme la relation entre une université et tous ses étudiants. Si les universités et les étudiants étaient directement liés, ce serait certainement source de confusion. La réalité est qu'il y a plusieurs niveaux ajoutés entre eux, d'abord il y a les départements, puis il y a les majeures, puis il y a les grades et enfin il y a les classes. Après ces quatre niveaux de cartographie, la relation devient beaucoup plus claire.

Il n'y a aucun problème qui ne puisse être résolu en ajoutant une couche. C'est une conclusion très importante. Si c'est le cas, ajoutez un autre calque. La même chose est vraie dans les ordinateurs.

Redis ajoute une autre couche entre les données et les nœuds, appelée slot. Parce que le slot est principalement lié au hachage, il est également appelé slot de hachage.

*** devient, les nœuds sont placés avec des slots, et les slots sont placés avec des données. Les emplacements résolvent le problème de la granularité, ce qui équivaut à augmenter la granularité, ce qui facilite le mouvement des données. La technologie de hachage est utilisée pour résoudre les problèmes de mappage. Elle utilise la valeur de hachage de la clé pour calculer l'emplacement où elle se trouve afin de faciliter la distribution des données.

Il y a des piles de livres sur votre table d'étude, qui sont extrêmement en désordre. Il est très difficile d'en trouver un. Vous achetez de grands bacs de rangement, triez les livres dans différents bacs en fonction de la longueur de leur titre et les placez sur la table.

De cette façon, il y a une boîte de rangement sur la table, et il y a des livres dans la boîte de rangement. Cela facilite le déplacement des livres, il suffit de prendre une boîte et c'est parti. Vous pouvez facilement trouver le livre dont vous avez besoin en mesurant simplement la longueur du titre et en vous dirigeant vers la case correspondante.

En fait, nous n'avons rien fait, nous avons juste acheté quelques cartons et emballé les livres dans les cartons selon certaines règles. Un geste aussi simple a complètement changé la situation qui était à l’origine un désastre. N'est-ce pas un peu magique ?

Un cluster ne peut avoir que 16384 emplacements, numérotés de 0 à 16383. Ces emplacements sont alloués à tous les nœuds maîtres du cluster et aucune politique d'allocation n'est requise. Vous pouvez spécifier quels emplacements numérotés sont attribués à quel nœud maître. Le cluster enregistrera la relation correspondante entre les nœuds et les emplacements.

Ensuite, vous devez hacher la clé, diviser le résultat par 16384 et prendre le reste. Le reste déterminera dans quel emplacement la clé tombe. emplacement = CRC16 (clé) % 16384.

Déplacez les données en unités d'emplacements. Le nombre d'emplacements étant fixe, il est plus facile à traiter, ce qui résout le problème du mouvement des données.

Utilisez la fonction de hachage pour calculer la valeur de hachage de la clé, afin que son emplacement correspondant puisse être calculé, puis utilisez la relation de mappage entre l'emplacement et le nœud stocké dans le cluster pour interroger le nœud où se trouve l'emplacement, Ainsi, les données et les nœuds sont cartographiés. De cette façon, le problème d'allocation de données est résolu.

Ce que je veux dire, c'est que les gens ordinaires n'apprendront que diverses technologies. Les experts se soucient davantage de la façon de sortir de la technologie et de chercher une solution ou une direction de réflexion, si vous allez dans cette direction, vous pourrez trouver quoi. tu veux. Tu veux la réponse.

Choix des opérations de commande du cluster

Tant que le client établit un lien avec un nœud du cluster, il peut obtenir toutes les informations sur les nœuds de l'ensemble du cluster. De plus, les informations de relation correspondantes de tous les emplacements de hachage et nœuds seront obtenues. Ces informations seront mises en cache sur le client car ces informations sont très utiles.

Le client peut envoyer une requête à n'importe quel nœud, donc après avoir obtenu une clé, à quel nœud doit-il envoyer la requête ? En fait, il s'agit simplement de déplacer la relation de mappage théorique entre l'ensemble de clés et les nœuds dans le cluster au client.

Le client doit donc implémenter la même fonction de hachage que le côté cluster. Calculez d'abord la valeur de hachage de la clé, puis prenez le reste de 16384. De cette façon, l'emplacement de hachage correspondant à la clé est trouvé et le client Le cache est utilisé. Les informations de relation correspondantes entre l'emplacement et le nœud peuvent être utilisées pour trouver le nœud correspondant à la clé.

Envoyez simplement la demande. Vous pouvez également mettre en cache la relation de mappage entre la clé et le nœud. La prochaine fois que vous demanderez la clé, vous obtiendrez directement le nœud correspondant sans avoir à le calculer à nouveau.

Bien que le cache du client n'ait pas été mis à jour, le cluster a changé, ce qui montre l'écart entre la théorie et la réalité. Il est très probable que la clé demandée au nœud correspondant ne se trouve plus sur ce nœud. Que doit faire ce nœud à ce moment-là ?

Ce nœud peut accéder au nœud où se trouve réellement la clé pour obtenir les données et les renvoyer au client. Il peut également indiquer directement au client que la clé n'est plus là, et attachez le nœud où se trouve maintenant l'information, permettant au client de la demander à nouveau, similaire à la redirection 302 de HTTP.

C'est en fait une question de choix et une question philosophique. Le résultat est que le cluster Redis a choisi cette dernière solution. Par conséquent, le nœud ne traite que les clés qu'il possède. Pour les clés qu'il ne possède pas, il renverra une erreur de redirection, c'est-à-dire -MOVED key 127.0.0.1:6381, et le client renverra la requête à ce nouveau nœud.

Le choix est donc une philosophie et une sagesse. Nous en reparlerons plus tard. Examinons d’abord une autre situation, qui présente certaines similitudes avec ce problème.

Redis a une commande qui peut apporter plusieurs clés à la fois, comme MGET que j'appelle ces commandes multi-clés. La demande de cette commande multi-touches est envoyée à un nœud. Il y a ici un problème potentiel. Je me demande si vous y avez pensé, c'est-à-dire que les multiples clés de cette commande doivent être situées sur le même nœud ? peut être divisé en Il existe deux situations.Si plusieurs clés ne sont pas sur le même nœud, le nœud ne peut renvoyer qu'une erreur de redirection. Cependant, plusieurs clés peuvent être situées sur plusieurs nœuds différents, et l'erreur de redirection renvoyée à ce moment-là sera. très spécial. C'est chaotique, donc le cluster Redis choisit de ne pas prendre en charge cette situation.

Si plusieurs clés se trouvent sur le même nœud, il n'y a en théorie aucun problème. Que le cluster Redis le prenne en charge dépend de la version Redis. Testez-le simplement vous-même lorsque vous l'utilisez.

Au cours de ce processus, nous avons découvert une chose très significative, c'est-à-dire qu'il est très nécessaire de mapper un ensemble de clés associées au même nœud. Cela peut améliorer l'efficacité et obtenir plusieurs valeurs à la fois via le multi-clé. commande. .

Alors la question est, comment nommer ces clés pour qu'elles tombent sur le même nœud ? Est-il possible que nous devions d'abord calculer une valeur de hachage puis prendre le reste ? Bien sûr, ce n’est pas le cas, Redis l’a déjà compris pour nous.

En raisonnant simplement, si vous voulez que deux clés soient sur le même nœud, leurs valeurs de hachage doivent être les mêmes. Pour que les valeurs de hachage soient les mêmes, les chaînes transmises dans la fonction de hachage doivent être les mêmes. Si nous ne transmettons que deux chaînes identiques, alors les deux chaînes seront traitées comme la même clé et les données suivantes écraseront les données précédentes.

Le problème ici est que nous utilisons la clé entière pour calculer la valeur de hachage, ce qui conduit au couplage de la clé et de la chaîne impliquée dans le calcul de la valeur de hachage. Elles doivent être découplées, c'est-à-dire la clé et la chaîne. impliqué dans le calcul de la valeur de hachage. Les chaînes sont liées mais différentes.

Redis nous propose une solution basée sur ce principe, appelée key hash tag. Regardons d'abord l'exemple, {user1000}.suivant, {user1000}.followers. Je pense que vous avez déjà vu l'astuce, qui consiste à utiliser uniquement la chaîne entre { et } dans la clé pour participer au calcul de la valeur de hachage.

Cela garantit que les valeurs de hachage sont les mêmes et tombent sur le même nœud. Mais les clés sont différentes et ne se couvriront pas. En utilisant des balises de hachage pour associer un ensemble de clés associées, le problème est résolu facilement et avec bonheur.

La résolution de problèmes repose sur une créativité et des idées ingénieuses, plutôt que sur l'utilisation d'une technologie et d'algorithmes exceptionnels. Voici Xiaoqiang, petit mais puissant.

Enfin, parlons de la philosophie du choix. La principale caractéristique de Redis est de mettre en œuvre le stockage clé-valeur et l'accès aux structures de données couramment utilisées dans les plus brefs délais, ainsi que d'effectuer les opérations associées sur ces structures de données. Nous choisissons d'affaiblir ou de ne pas traiter tout ce qui n'a rien à voir avec le noyau ou qui entraînera le noyau. Ceci afin de garantir que le noyau est simple, rapide et stable.

En fait, face à l'ampleur et à la profondeur, redis a choisi la profondeur. Par conséquent, le nœud ne traite pas les clés qu’il ne possède pas et le cluster ne prend pas en charge les commandes pour plusieurs clés. De cette manière, d'une part, il est possible de répondre rapidement au client et, d'autre part, une grande quantité de transmission et de fusion de données peut être évitée au sein du cluster.

Modèle monothread

Il n'y a qu'un seul thread dans chaque nœud du cluster redis chargé d'accepter et d'exécuter toutes les requêtes envoyées par le client. Techniquement, les E/S multiplexées sont utilisées, à l'aide de la fonction Linux epoll, afin qu'un seul thread puisse gérer plusieurs connexions socket.

De plus, il y a les raisons suivantes pour choisir un seul thread :

1 Redis fonctionne sur la mémoire et est extrêmement rapide (10W+QPS)

2 Le temps global est principalement consommé dans le réseau sur la transmission

. 3. Si le multi-threading est utilisé, une synchronisation multi-thread est requise, ce qui deviendra compliqué à mettre en œuvre

4 Le temps de verrouillage du thread dépasse même le temps de fonctionnement de la mémoire

5. Multi-threading Les changements de contexte fréquents consomment. plus de temps CPU

6. De plus, les threads uniques prennent naturellement en charge les opérations atomiques, et le code monothread est plus simple à écrire

Transactions

Tout le monde sait que les transactions sont multiples. Les opérations sont regroupées et l'une ou l'autre est exécutée (avec succès) ou aucun n'est exécuté (annulé). Redis prend également en charge les transactions, mais ce n'est peut-être pas ce que vous souhaitez.

Les transactions Redis peuvent être divisées en deux étapes : définir la transaction et exécuter la transaction. Après avoir démarré une transaction, ajoutez toutes les commandes à exécuter dans l'ordre. Ceci définit une transaction. Vous pouvez exécuter la transaction à l'aide de la commande exec à ce stade, ou l'abandonner avec la commande throw.

Vous pouvez espérer que les clés qui vous intéressent ne veulent pas être exploitées par d'autres avant le début de votre transaction. Vous pouvez ensuite utiliser la commande watch pour surveiller ces clés si ces clés sont actionnées par d'autres commandes avant de commencer l'exécution de la transaction. sera annulé. Vous pouvez également utiliser la commande unwatch pour annuler la surveillance de ces clés.

Les transactions Redis ont les caractéristiques suivantes :

1. Si une erreur se produit avant le démarrage de la transaction, toutes les commandes ne seront pas exécutées

2 Une fois démarrées, toutes les commandes sont garanties d'être exécutées en séquence sans être interrompues.

3 , Si une erreur est rencontrée lors de l'exécution, elle continuera à s'exécuter et ne s'arrêtera pas

4. Si une erreur est rencontrée lors de l'exécution, elle ne sera pas annulée

La lecture de la description ci-dessus me fait me demander si c'est possible, c'est ce qu'on appelle une transaction. Évidemment, cela est complètement différent de ce que nous entendons habituellement par transactions, puisqu’il n’est même pas garanti qu’elles soient atomiques. Redis ne prend pas en charge l'atomicité car il ne prend pas en charge la restauration, et il y a une raison pour laquelle cette fonctionnalité n'est pas prise en charge.

Raisons pour ne pas prendre en charge la restauration :

1. Redis pense que les échecs sont causés par une mauvaise utilisation des commandes

2 Redis fait cela pour que la mise en œuvre interne soit simple et rapide

3. Cela ne résout pas tous les problèmes

Haha, c'est la clause overlord, il semble donc qu'il n'y ait pas beaucoup de transactions Redis utilisées

pipeline

Le processus d'interaction entre le client et le cluster est un blocage sérialisé, c'est-à-dire le le client envoie Après une commande, vous devez attendre que la réponse revienne avant d'envoyer la deuxième commande. Il s'agit d'un temps d'aller-retour. Si vous avez beaucoup de commandes et que vous les exécutez une par une, ce sera très lent.

Redis fournit une technologie de pipeline qui permet au client d'envoyer plusieurs commandes en même temps sans attendre une réponse du serveur. Une fois toutes les commandes envoyées, toutes les réponses à ces commandes seront reçues dans l'ordre. Cela permet de gagner beaucoup de temps et d’améliorer l’efficacité.

Êtes-vous assez intelligent pour réaliser un autre problème ? Plusieurs commandes sont plusieurs clés. N'est-ce pas l'opération multi-touches mentionnée ci-dessus ? Alors la question est : comment vous assurer que ces plusieurs clés sont identiques ? haha, le cluster Redis a de nouveau abandonné le support des pipelines.

Cependant, cela peut être simulé côté client, c'est-à-dire en utilisant plusieurs connexions pour envoyer des commandes à plusieurs nœuds en même temps, puis en attendant que tous les nœuds renvoient des réponses, puis en les triant dans l'ordre dans lequel le les commandes sont envoyées et les renvoient au code utilisateur. Oups, c'est tellement gênant.

Protocole

Comprenez brièvement le protocole redis et connaissez le format de transmission de données redis.

Protocole d'envoi de la requête :

*Nombre de paramètres CRLF$Nombre d'octets du paramètre 1 CRLF Données du paramètre 1 CRLF...$Nombre d'octets du paramètre N CRLF Données du paramètre N CRLF

Par exemple, nom du SET lixinjie , les données réelles envoyées sont :

*3rn$3rnSETrn$4rnnamern$8rnlixinjiern

Le protocole d'acceptation de la réponse :

Réponse sur une seule ligne, le premier octet est +

Message d'erreur, le dernier octet est -

Nombre entier, le premier octet est :

Réponse par lots, le premier octet est $

Réponse multiple par lots, le premier octet est *

Par exemple,

+OKrn

-ERR Opération contrern

:1000rn