Lorsque vous commencez à utiliser Redis, il est facile de croire que vous n'aurez jamais besoin de l'alléger au-delà des paramètres par défaut. Le problème est que à mesure que votre application se développe, vous aurez finalement besoin de plus de mémoire, de processeur et de capacité de débit pour répondre aux besoins de votre entreprise. Dans cet article, nous vous montrerons comment le cluster redis évolue avec un fragment pour vous donner la capacité supplémentaire dont vous avez besoin pour gérer votre entreprise en douceur et grandir dans le futur. Nous apprendrons spécifiquement comment le cluster Redis fournit un débit élevé avec un fragment.

Évolutivité

Il existe deux approches communes pour mettre à l'échelle un serveur: la mise à l'échelle verticale et la mise à l'échelle horizontale. La mise à l'échelle ou l'échelle verticale est l'endroit où vous ajoutez plus d'énergie et de ressources à votre serveur, comme plus de processeurs, de mémoire et de stockage, qui est coûteux. D'un autre côté, la mise à l'échelle horizontale ajoute plusieurs nœuds à votre pool de ressources existant. C'est ce qu'on appelle la mise à l'échelle. Ainsi, en fonction de vos limites et exigences, c'est à vous d'avoir une seule instance de serveur plus grande ou de déployer plusieurs nœuds de serveur.

Supposons que vous avez 100 Go de RAM et que vous avez besoin de conserver 200 Go de données. Dans ce cas, vous avez deux choix:

• Évoluer en ajoutant plus de RAM au système
• Évoluer en ajoutant une autre instance de serveur avec 100 Go de RAM

Si vous avez atteint la limite de RAM maximale dans votre infrastructure, alors la mise à l'échelle est l'approche idéale. De plus, la mise à l'échelle augmentera le débit de la base de données par une énorme marge.

Redis Sharding

C'est un fait connu que Redis fonctionne sur un seul fil. Ainsi, Redis n'est pas capable d'utiliser plusieurs cœurs du CPU de votre serveur pour traiter les commandes. Par conséquent, ajouter plus de cœurs de processeur ne vous donne pas beaucoup de débit ou de performances avec redis. Ce n'est pas le cas pour diviser vos données entre plusieurs instances de serveur. Ajout de plusieurs serveurs et distribution de l'ensemble de données entre ceux qui permettent le traitement des demandes du client parallèle, ce qui augmente le débit. De plus, les performances globales peuvent augmenter près de linéairement.

Cette approche de division ou de distribution de données entre plusieurs serveurs avec une mise à l'échelle est appelée fragment. Tous les serveurs qui stockent des parties des données sont appelés fragments.

Comment se déroule - le fragment algorithmique

L'une des principales préoccupations concernant le fragment était de savoir comment localiser une clé donnée parmi plusieurs nœuds redis. Parce qu'une clé donnée peut être stockée dans tous les éclats disponibles, interroger tous les éclats pour trouver une clé spécifique n'est pas la meilleure option. Ainsi, il devrait y avoir un moyen de cartographier chaque clé d'un éclat spécifique, et Redis utilise une stratégie de fragment algorithmique.

L'approche la plus courante consiste à calculer une valeur de hachage en utilisant le nom de la clé Redis et le modulo. Ensuite, divisez-le par les éclats redis disponibles dans le système.

Hash_slot = crc16 (clé) mod 16384

C'est une assez bonne solution tant que le nombre total d'éclats est constant. Chaque fois que vous ajoutez une nouvelle instance Reids Server, la valeur résultante pour une clé donnée peut changer car le nombre total d'éclats a augmenté. Cela finira par interroger le mauvais Shard Redis. Par conséquent, vous devez suivre le processus de retournement en calculant le nouveau fragment pour chaque clé et en transférant des données sur le serveur correct, qui est lourd et non une tâche triviale si votre nombre total de fragment augmente de temps à autre.

Redis utilise une nouvelle entité logique appelée hachage Pour éviter ce problème. Plusieurs emplacements de hachage sont disponibles pour un fragment donné, et un seul emplacement de hachage peut contenir plusieurs clés Redis. Il y a 16384 créneaux de hachage dans un cluster de base de données redis qui reste inchangé. La division modulo est réalisée avec le nombre de créneaux de hachage au lieu du nombre de fragment. Il fournit la position correcte de la fente de hachage pour la clé spécifiée même lorsque le nombre de fragments a augmenté. Il simplifie le processus de remodelage en déplaçant les créneaux de hachage d'un éclat à la nouvelle qui divise les données à travers les différentes instances Redis selon les exigences.

Avantages de Redis Sharding

Redis Sharding permet plusieurs avantages à votre système de base de données avec un minimum de modifications.

Haut débit

Étant donné que Redis est unique, le traitement de plusieurs demandes de clients ne peut pas traiter parallèle à l'aide de plusieurs cœurs de CPU. Ainsi, l'ajout de nouveaux éclats ou des instances de serveur garantit que vous pouvez effectuer des opérations Redis en parallèle. Il augmente les opérations par seconde dans votre base de données Redis, ce qui vous donne finalement un débit élevé.

La haute disponibilité

Avec l'approche de fragment, le cluster Redis peut mettre en place une architecture maître-replice qui garantit une grande disponibilité et une durabilité.

Lire des répliques

Sharding vous permet de conserver une copie exacte de vos données et de fournir des opérations de lecture via des instances de redis distinctes, ce qui augmente les performances de votre exécution de requête en lecture.

En dehors de ces avantages, la rupture peut provoquer des situations de cerveau fendu lorsque vous avez un nombre uniforme d'éclats dans le cluster redis. Donc, garder un nombre étrange d'éclats dans votre cluster redis est recommandé.

Conclusion

Pour résumer, Redis Sharding partage des données entre plusieurs serveurs, ce qui permet une mise à l'échelle et un débit élevé pour votre base de données. Comme discuté, Redis utilise une stratégie de fragment algorithmique pour pointer des demandes de clients à l'éclat correct. Cela présente certains inconvénients lorsque le nombre total d'éclats augmente. Ainsi, au lieu du nombre total d'éclats, Redis utilise le nombre de créneaux de hachage pour calculer l'écroit approprié. Avec le rupture introduit, les bases de données redis offrent une haute disponibilité, un débit élevé et des performances élevées.