Explication détaillée du partitionnement Redis

Le partitionnement est le processus de division de vos données en plusieurs instances Redis afin que chaque instance ne contienne qu'un sous-ensemble de toutes les clés. La première partie de cet article vous présentera le concept de sharding, et la deuxième partie vous montrera les options de sharding Redis.

Ce que le sharding peut faire

Le sharding de Redis a deux objectifs principaux :

Autoriser l'utilisation De nombreux ordinateurs ont le mémoire combinée pour prendre en charge des bases de données plus volumineuses. Sans partitionnement, vous êtes limité à la quantité de mémoire qu’une seule machine peut prendre en charge.

2. Permet de faire évoluer la puissance de calcul vers plusieurs cœurs ou plusieurs serveurs, et de faire évoluer la bande passante réseau vers plusieurs serveurs ou plusieurs adaptateurs réseau.

Bases du partage

Il existe de nombreux critères (critères) de partage différents. Supposons que nous ayons 4 instances Redis R0, R1, R2, R3 et de nombreuses clés représentant les utilisateurs, comme user:1, user:2,... etc. Nous pouvons trouver différentes manières de sélectionner une clé spécifique à stocker dans quelle instance . En d’autres termes, il existe de nombreuses façons différentes de mapper une clé à un serveur Redis spécifique.

L'un des moyens les plus simples d'effectuer un partitionnement est le partitionnement par plage, qui termine le partitionnement en mappant la plage d'un objet à une instance Redis spécifiée. Par exemple, je pourrais supposer qu'un utilisateur entre l'instance R0 de l'ID 0 à l'ID 10000, un utilisateur entre l'instance R1 de l'ID 10001 à l'ID 20000, et ainsi de suite.

Cette approche fonctionne et est réellement utilisée dans la pratique, cependant, elle présente l'inconvénient de nécessiter une table mappant les plages aux instances. Cette table doit être gérée, et différents types d'objets nécessitent une table, donc le partitionnement de plage n'est souvent pas conseillé dans Redis car il est beaucoup moins efficace que l'alternative de partitionnement.

Une alternative au partitionnement de plage est le partitionnement par hachage. Ce modèle fonctionne avec n'importe quelle clé, il ne nécessite pas que la clé soit sous la forme nom_objet : , c'est aussi simple que ceci :

1 Utilisez une fonction de hachage (par exemple, la fonction de hachage crc32) pour convertir. le nom de la clé à un numéro. Par exemple, si la clé est foobar, crc32(foobar) affichera quelque chose comme 93024922.

2. Modulo ces données pour les convertir en un nombre compris entre 0 et 3 afin que ce nombre puisse être mappé sur l'une de mes 4 instances Redis. 93024922 modulo 4 est égal à 2, donc je sais que ma clé foobar doit être stockée dans l'instance R2. Remarque : L'opération modulo renvoie le reste de l'opération de division, qui est toujours implémentée en tant qu'opérateur % dans de nombreux langages de programmation.

Il existe de nombreuses autres façons de fragmenter, comme vous pouvez le voir dans ces deux exemples. Une forme avancée de partage de hachage est appelée hachage cohérent et est mise en œuvre par certains clients et courtiers Redis.

Différentes implémentations du sharding

Le sharding peut être entrepris par différentes parties de la pile logicielle.

1. Le partitionnement côté client signifie que le client sélectionne directement le nœud correct pour écrire et lire la clé spécifiée. De nombreux clients Redis implémentent le partitionnement côté client.

2. Le partitionnement assisté par proxy signifie que notre client envoie des requêtes à un proxy capable de comprendre le protocole Redis, au lieu d'envoyer des requêtes directement à l'instance Redis. Le proxy garantira que nos demandes sont transmises à la bonne instance Redis en fonction du mode de partitionnement configuré et renverra une réponse au client. Twemproxy, un proxy pour Redis et Memcached, implémente le partitionnement assisté par proxy.

3. Le routage des requêtes signifie que vous pouvez envoyer votre requête à une instance aléatoire, et cette instance garantira que votre requête est transmise au bon nœud. Redis Cluster implémente une forme hybride de routage des requêtes avec l'aide des clients (les requêtes ne sont pas transmises directement d'une instance Redis à une autre, mais le client reçoit une redirection vers le bon nœud).

Inconvénients du sharding

Certaines fonctionnalités de Redis ne fonctionnent pas bien avec le sharding :

1.Opérations impliquant plusieurs clés. ne sont généralement pas pris en charge. Par exemple, vous ne pouvez pas effectuer une intersection sur des clés mappées sur deux instances Redis différentes (en fait il existe un moyen de le faire, mais pas directement).

2. Les transactions impliquant plusieurs clés ne peuvent pas être utilisées.

3. La granularité du partitionnement est la clé, vous ne pouvez donc pas utiliser une grande clé pour partitionner l'ensemble de données, comme un grand ensemble ordonné.

4. Lorsque le partitionnement est utilisé, le traitement des données devient plus complexe. Par exemple, vous devez traiter plusieurs fichiers RDB/AOF lors de la sauvegarde des données, vous devez agréger les fichiers persistants de plusieurs instances et hôtes.

5. L'ajout et la suppression de capacité sont également compliqués. Par exemple, Redis Cluster a la capacité d'ajouter et de supprimer dynamiquement des nœuds au moment de l'exécution pour prendre en charge un rééquilibrage transparent des données, mais d'autres méthodes, telles que le partitionnement côté client et les proxys, ne prennent pas en charge cette fonctionnalité. Cependant, il existe une technologie appelée presharding qui peut aider à ce stade.

Stockage ou cache de données

Bien que le partitionnement Redis soit conceptuellement le même, que vous utilisiez Redis comme magasin de données ou cache, mais en tant que données, il existe un limitation en matière de stockage. Lorsque Redis est utilisé comme magasin de données, une clé donnée est toujours mappée à la même instance Redis. Lorsque Redis est utilisé comme cache, ce n'est pas un gros problème si un nœud est indisponible et qu'un autre nœud est utilisé. Changer le mappage des clés et des instances selon nos souhaits améliore la disponibilité du système (c'est-à-dire la capacité du système à le faire). répondre à nos questions) .

Les implémentations de hachage cohérentes permettent souvent de basculer vers d'autres nœuds si le nœud préféré pour une clé donnée n'est pas disponible. De même, si vous ajoutez un nouveau nœud, certaines données commenceront à être stockées dans ce nouveau nœud.

Les principaux concepts ici sont les suivants :

1. Si Redis est utilisé comme cache, il est facile d'utiliser un hachage cohérent pour réaliser une mise à l'échelle vers le haut et vers le bas.

2. Si Redis est utilisé comme stockage, un mappage clé-nœud fixe est utilisé, donc le nombre de nœuds doit être fixe et ne peut pas être modifié. Sinon, lors de l'ajout ou de la suppression de nœuds, vous avez besoin d'un système prenant en charge le rééquilibrage des clés entre les nœuds. Actuellement, seul Redis Cluster peut le faire, mais Redis Cluster est encore en phase bêta et n'a pas encore été envisagé pour une utilisation dans un environnement de production.

Pré-sharding

Nous savons déjà qu'il y a un problème avec le sharding À moins que nous n'utilisions Redis comme cache, en ajoutant et en supprimant des nœuds. est un problème. Une chose délicate à faire, il est beaucoup plus simple d'utiliser une clé fixe et un mappage d'instance.

Cependant, les besoins en stockage de données peuvent changer constamment. Aujourd'hui, je peux vivre avec 10 nœuds Redis (instances), mais demain j'aurai peut-être besoin de 50 nœuds.

Étant donné que Redis a une empreinte mémoire assez faible et est léger (une instance inactive n'utilise que 1 Mo de mémoire), une solution simple consiste à démarrer plusieurs instances depuis le début. Même si vous démarrez avec un seul serveur, vous pouvez décider dès le premier jour de vivre dans un monde distribué et d'utiliser le partitionnement pour exécuter plusieurs instances Redis sur un seul serveur.

Vous pouvez choisir un grand nombre d'instances dès le départ. Par exemple, 32 ou 64 instances satisferont la plupart des utilisateurs et offriront suffisamment d'espace pour une croissance future.

De cette façon, lorsque votre stockage de données doit croître et que vous avez besoin de plus de serveurs Redis, il vous suffit de déplacer simplement les instances d'un serveur à un autre. Lorsque vous ajoutez le premier serveur, vous devez déplacer la moitié des instances Redis du premier serveur vers le second, et ainsi de suite.

Grâce à la réplication Redis, vous pouvez déplacer des données avec peu ou pas de temps d'arrêt :

1 Démarrez une instance vide sur votre nouveau serveur.

2. Déplacez les données et configurez la nouvelle instance comme service esclave de l'instance source.

3. Arrêtez votre client.

4. Mettez à jour la configuration de l'adresse IP du serveur de l'instance déplacée.

5. Envoyez la commande SLAVEOF NO ONE au nœud esclave sur le nouveau serveur.

6. Démarrez votre client avec la nouvelle configuration mise à jour.

7. Enfin, fermez les instances qui ne sont plus utilisées sur l'ancien serveur.

Mise en œuvre du partitionnement Redis

Le cluster Redis est le moyen privilégié pour le partitionnement automatique et la haute disponibilité. Il n’est pas encore entièrement disponible pour une utilisation en production, mais il est entré en phase bêta.

Une fois que Redis Cluster sera disponible et que les clients prenant en charge Redis Cluster seront disponibles, Redis Cluster deviendra la norme de facto pour le partitionnement Redis.

Redis Cluster est un modèle hybride de routage de requêtes et de partitionnement client.

Twemproxy est un proxy développé par Twitter qui prend en charge les protocoles Memcached ASCII et Redis. Il est monothread, écrit en C et s'exécute très rapidement. Il s'agit d'un projet open source sous licence Apache 2.0.

Twemproxy prend en charge le partitionnement automatique sur plusieurs instances Redis et la prise en charge facultative de l'exclusion de nœud si le nœud n'est pas disponible (cela modifiera le mappage des clés aux instances, vous ne devez donc utiliser Redis que comme cache. Utilisez uniquement cette fonctionnalité) .

Ce n'est pas un point d'échec unique car vous pouvez démarrer plusieurs proxys et demander à vos clients de se connecter au premier qui accepte la connexion.

Une alternative à Twemproxy consiste à utiliser un client qui implémente le partitionnement côté client via un hachage cohérent ou d'autres algorithmes similaires. Il existe plusieurs clients Redis qui prennent en charge un hachage cohérent, tels que redis-rb et Predis.

Pour plus de connaissances sur Redis, veuillez faire attention à la colonne Tutoriel de base de données Redis.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!