Interprétation du hachage (ziplist) dans Redis 6.0

Table des matières

Présentation des types de données de hachage

Le type de données de hachage dans Redis utilise deux formats d'encodage : ziplist (liste compressée), hashtable (table de hachage). Dans le fichier de configuration redis.conf, il y a les deux paramètres suivants, ce qui signifie : lorsque le nombre de nœuds est inférieur à 512 et la chaîne Lorsque la longueur est inférieure ou égale à 64, l'encodage ziplist sera utilisé.

hash-max-ziplist-entries 512    
hash-max-ziplist-value 64

ziplist (liste compressée)

introduction de base

ziplist est une liste doublement chaînée spécialement codée, conçue pour être efficace en termes de mémoire . Il stocke les valeurs de chaîne et d'entier, où les entiers sont codés comme des entiers réels plutôt que comme une séquence de caractères. Il permet les opérations push et pop de chaque côté de la liste en un temps O(1). Cependant, comme chaque opération nécessite une réallocation de la mémoire utilisée par ziplist , la complexité réelle est liée à la quantité de mémoire utilisée par ziplist.

ziplist est une liste spéciale doublement chaînée. Contrairement aux listes chaînées ordinaires qui utilisent des pointeurs avant et arrière pour les associer, elle est stockée dans une mémoire continue.

Explication détaillée de la structure

zlbytes : entier non signé de 32 bits, enregistre l'espace occupé par l'ensemble de la structure de la liste zip. Bien entendu, cela inclut également les zlbytes eux-mêmes. Cette structure a une grande utilité, c'est-à-dire que lorsque vous devez modifier la liste zip, vous pouvez connaître sa taille sans la parcourir.
zltail : entier non signé de 32 bits, enregistre le décalage de la dernière entrée dans toute la liste zip. Par conséquent, il n'est pas nécessaire de parcourir une seule fois lors de l'exécution d'une opération POP à la queue.
zllen : entier non signé de 16 bits, enregistre le nombre d'entrées, il ne peut donc représenter que 2^16. Cependant, Redis a réalisé un traitement particulier : lorsque le nombre d'entités dépasse 2^16, la valeur est fixée à 2^16 - 1. Donc à ce stade, si vous voulez connaître le nombre de toutes les entités, vous devez parcourir toute la structure.
entrée : la structure qui stocke réellement les données.
zlend : entier non signé de 8 bits, fixé à 255 (0xFF). C'est l'identifiant de fin de ziplist.

L'entrée contient des attributs tels que previous_entry_length, encoding et content.

Le premier cas : structure générale <prevlen> <encoding> <entry-data>

prevlen : la taille de l'entrée précédente ;
encodage : différentes valeurs dans différentes situations, utilisées pour représenter le type et la longueur de l'entrée actuelle ;
Entry-Data : réellement utilisé pour stocker les données représentées par Entry ;

Le deuxième cas : la structure d'entrée à cet instant : <prevlen> <encoding>

Lorsque le type int est stocké dans l'entrée, l'encodage et les données d'entrée seront combinés et représentés dans l'encodage. Pour le moment, il n'y a pas de champ de données d'entrée ;
Dans Redis, lors du stockage des données, il essaiera d'abord de convertir la chaîne en stockage int pour économiser de l'espace ;

Encodage prevlen : lorsque la longueur de l'élément précédent est inférieure à 254 (255 est utilisé pour zlend), la longueur de prevlen est de 1 octet et la valeur est la longueur de l'entrée précédente. Si la longueur est supérieure ou égale à 254, prevlen est représenté par 5 octets, le premier octet est défini sur 254 et les 4 octets suivants stockent un entier petit-boutiste non signé, indiquant la longueur de l'entrée précédente ;

codage:

La longueur et la valeur du codage dépendent du fait que la valeur int ou chaîne soit enregistrée, ainsi que de la longueur des données ;

Les deux premiers chiffres sont utilisés pour indiquer le type. Lorsqu'il est "11", cela signifie que l'entrée stocke un type int, et les deux autres signifient que l'entrée stocke une chaîne ;

Lors du stockage de int :

| 11 000000| l'encodage est de 3 octets, les 2 derniers octets représentent un int16 ;

| 11 010000| l'encodage est de 5 octets, les 4 derniers octets représentent un int32 ;

| 11 100000| l'encodage est de 9 octets, et les 8 derniers octets représentent un int64 ;

| 11 110000| l'encodage est de 4 octets, et les 3 derniers octets représentent un entier signé ;

| 11 111110| l'encodage est de 2 octets, et le dernier octet représente un type entier signé ;

| 11 11xxxx| La longueur de codage est de seulement 1 octet et xxxx représente une valeur entière comprise entre 0 et 12 ;

Lors du stockage d'une chaîne :

| 00 pppppp| : À l'heure actuelle, la longueur de codage est de 1 octet. Les six derniers bits de l'octet représentent la longueur de la chaîne stockée dans l'entrée. Comme il s'agit de 6 bits, la longueur de la chaîne stockée dans l'entrée ne peut pas dépasser 63 ;

| 01 pppppp|qqqqqqqqq| À ce stade, la longueur de codage est de deux octets ; à ce stade, les 14 derniers bits de codage sont utilisés pour stocker la longueur de la chaîne, et la longueur ne peut pas dépasser 16 383 ;

| 10 000000|qqqqqqqq|rrrrrrrr|ssssssss|ttttttt| À ce stade, la longueur de codage est de 5 octets et les 4 octets suivants sont utilisés pour représenter la longueur de la chaîne stockée dans le codage. La longueur ne peut pas dépasser 2 ^ 32 - 1;

problème de mise à jour de la chaîne

Le champ prevlen dans l'entrée représente la longueur de l'entrée précédente. Il existe deux valeurs, 1 octet ou 5 octets.
Lorsque la longueur de l'entrée avant une entrée change, il sera nécessaire d'augmenter la taille du champ prevlen de l'entrée. entrée pour stocker la longueur de l'entrée précédente, s'il y a plusieurs entrées consécutives d'une capacité proche de 254, la taille précédente de plusieurs entrées devra être étendue et une mise à jour dite en cascade se produira.
L'essence de cette mise à jour est un changement dans la taille précédente, qui se produit dans deux situations :

La première consiste à développer (1 octet -> 5 octets),
L'un diminue (5 octets -> 1 octet)