Je ne sais pas quel client vous utilisez. Différents clients ont l'implémentation la plus basique de la distribution, mais ce sont des implémentations client lors de l'ajout et de la suppression de nœuds, vous devez recalculer le hachage et migrer les données vous-même. Redis 3 prendra en charge le serveur, ce qui rendra les choses beaucoup plus simples.

Fondamentalement, l'implémentation actuelle du client est basée sur un hachage cohérent comme l'a dit @TechAd. Par exemple, Redis::Distributed est disponible pour les clients Ruby. Il est également très simple de diviser les données 4G en deux machines en fonction de vos besoins. . https est déjà disponible ://github.com/yankov/redis-migra... Vous pouvez l'utiliser directement Jetons un coup d'œil à l'implémentation. C'est en fait très simple.

J'espère que cela aide.

Il est recommandé de rechercher des algorithmes associés de hachage cohérent. L'idée générale est de créer un itinéraire sur le client, de créer un hachage pour la clé, puis de modifier 2, de stocker la valeur-clé à 0 et 1 respectivement. sur deux machines, il en va de même lors de la lecture. Vous pouvez vous référer à memcache, je vous donnerai un lien de référence http://blogread.cn/it/article/5271

Vous pouvez utiliser l'approche 3L, ou la manière la plus directe est de séparer les données au niveau de la couche métier et de les écrire dans la configuration. Cela sera très pratique lors du fractionnement à l'avenir et la logique est simple si vous le souhaitez vraiment. besoin de le faire Distribué, il est recommandé d'utiliser mongoDB

Si vous n'avez pas besoin de Pepline, il est recommandé d'utiliser https://github.com/twitter/twemproxy Proxy de sortie Twitter, hachage automatique, basculement automatique

Demandez, twemproxy ne prend-il pas en charge la commutation automatique actif/veille ?

如果你是用redis cluster来做这个数据迁的话，可以看看其官方的介绍：
En supposant que votre ensemble de données préexistant soit divisé en N maîtres, où N = 1 si vous n'avez pas de partitionnement préexistant, les étapes suivantes sont nécessaires pour migrer votre ensemble de données vers Redis Cluster :
Arrêtez vos clients. Aucune migration automatique en direct vers Redis Cluster n’est actuellement possible. Vous pourrez peut-être le faire en orchestrant une migration en direct dans le contexte de votre application/environnement.
Générez un fichier d'ajout uniquement pour tous vos N maîtres à l'aide de la commande BGREWRITEAOF et en attendant que le fichier AOF soit complètement généré.
Enregistrez vos fichiers AOF de aof-1 à aof-N quelque part. À ce stade, vous pouvez arrêter vos anciennes instances si vous le souhaitez (cela est utile car dans les déploiements non virtualisés, vous devez souvent réutiliser les mêmes ordinateurs).
Créez un cluster Redis composé de N maîtres et de zéro esclave. Vous ajouterez des esclaves plus tard. Assurez-vous que tous vos nœuds utilisent le fichier d'ajout uniquement pour la persistance.
Arrêtez tous les nœuds du cluster, remplacez leur fichier d'ajout uniquement par vos fichiers d'ajout uniquement préexistants, aof-1 pour le premier nœud, aof-2 pour le deuxième nœud, jusqu'à aof-N.
Redémarrez vos nœuds Redis Cluster avec les nouveaux fichiers AOF. Ils se plaindront du fait qu'il y a des clés qui ne devraient pas être là selon leur configuration.
Utilisez la commande redis-trib fix afin de réparer le cluster afin que les clés soient migrées en fonction des emplacements de hachage que chaque nœud fait autorité ou non.
Utilisez redis-trib check à la fin pour vous assurer que votre cluster fonctionne correctement.
Redémarrez vos clients modifiés pour utiliser une bibliothèque client compatible Redis Cluster.w