Sharding Redis (cache distribué)

Le partitionnement est le processus de division de vos données en plusieurs instances Redis, de sorte que chaque instance ne contienne qu'un sous-ensemble de toutes les clés (Recommandations associées : Tutoriel Redis)

1 À quoi sert le sharding

Le sharding de Redis a deux objectifs principaux :

• Permet la combinaison mémoire de nombreux ordinateurs à utiliser 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.

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

2 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 bien d'autres clés représentant les utilisateurs, comme user:1, user:2, ... etc. Nous pouvons trouver différentes façons de choisir dans quelle instance une clé spécifique est stockée. 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 peux supposer que l'utilisateur entre l'instance R0 de l'ID 0 à l'ID 10000 et que l'utilisateur entre l'instance R1 de l'ID 10001 à l'ID 20000.

Cette approche fonctionne et est réellement utilisée dans la pratique, cependant, cela présente l'inconvénient de nécessiter une table qui mappe les plages aux instances.

Cette table doit être gérée et différents types d'objets nécessitent une table, donc le partage de plage n'est souvent pas conseillé dans Redis car c'est beaucoup moins efficace que les autres alternatives de partitionnement.

Une alternative au partitionnement de plage est le partitionnement par hachage

Ce mode fonctionne avec n'importe quelle clé et ne nécessite pas que la clé soit de la forme nom_objet : , c'est aussi simple que cela

• Utilisez une fonction de hachage (par exemple, la fonction de hachage crc32) pour convertir le nom de la clé en nombre. Par exemple, si la clé est foobar, crc32(foobar) affichera quelque chose comme 93024922.

• 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.

3 Implémentation du Sharding (Théorie)

La fragmentation peut être entreprise par différentes parties de la pile logicielle.

• Partitionnement côté client

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.

• Partitionnement assisté par proxy<.>

Notre client envoie la demande à un proxy capable de comprendre le protocole Redis au lieu d'envoyer la demande directement à l'instance Redis.

Le proxy veillera à ce que nos demandes soient transmises au bon Redis. instance en fonction du mode de partitionnement configuré et renvoie une réponse au client

Twemproxy, le proxy de Redis et Memcached, implémente le fractionnement assisté par proxy de la tablette.

• Routage des requêtes

Vous pouvez envoyer votre requête à une instance aléatoire, et cette instance garantira de transmettre votre requête au bon nœud.

Redis Cluster implémente une forme hybride de routage de requêtes avec l'aide de clients (les requêtes ne sont pas transmis directement d'une instance Redis à une autre, mais le client reçoit une redirection vers le bon nœud).

4 Inconvénients du sharding

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

• Les opérations impliquant plusieurs clés ne sont généralement pas prises 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

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

• 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é

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

• L'ajout et la suppression de capacité sont également complexes. 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.

5 Stockage OU Cache

Bien que le partitionnement Redis soit conceptuellement le même, que vous utilisiez Redis comme magasin de données ou comme cache, il existe une limitation importante lorsqu'il est utilisé comme magasin de données. 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 concepts principaux ici sont les suivants :

• 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.

• Si Redis est utilisé comme stockage, un mappage clé-nœud fixe est utilisé, le nombre de nœuds doit donc ê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 le cluster Redis peut le faire.

6 Pré-partage

. Nous connaissons déjà un problème de partitionnement. À moins que nous n'utilisions Redis comme cache, l'ajout et la suppression de nœuds sont une tâche délicate. Il est beaucoup plus simple d'utiliser un mappage de clé fixe et 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 :

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

• Déplacez les données et configurez la nouvelle instance en tant que service esclave de l'instance source.

• Arrêtez votre client.

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

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

• Lancez votre client avec la nouvelle configuration mise à jour.

• Enfin, arrêtez les instances de l'ancien serveur qui ne sont plus utilisées.

7 Implémentation du partitionnement (Pratique)

Jusqu'à présent, nous avons discuté du partitionnement Redis en théorie, mais qu'en est-il de la pratique ? Quel système utiliser ?

7.1 Redis Cluster

Redis Cluster est le moyen préféré de partitionnement automatique et de haute disponibilité.

Une fois que Redis Cluster est disponible et prend en charge Redis Cluster Une fois le client disponible, Redis Cluster deviendra le standard de facto pour le partitionnement Redis.

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

7.2 Twemproxy

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. 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.

Fondamentalement, Twemproxy est une couche intermédiaire entre le client et l'instance Redis, nous permettant de gérer nos fragments de manière fiable avec un minimum de complexité supplémentaire. Il s'agit de la méthode actuellement recommandée pour gérer le partitionnement Redis.

7.3 Clients prenant en charge le hachage cohérent

Une alternative à Twemproxy consiste à utiliser l'implémentation Clients avec 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.

Veuillez consulter la liste complète des clients Redis pour voir s'il existe un client mature qui prend en charge votre langage de programmation et implémente un hachage cohérent.

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!