Si vous mettez le maître et l'esclave sur la même machine, il y aura des problèmes :

1. Le maître et l'esclave doivent occuper de la mémoire lors de l'exécution, et la mémoire de la machine peut ne pas être suffisante

2. Si la machine est en panne, éteinte ou si le réseau est déconnecté, alors il n'y a pas de haute disponibilité pour le maître et l'esclave.

Il est préférable de mettre le maître et l'esclave sur des machines différentes.

Quant à savoir pourquoi c'est 3 au lieu de 2. C’est la meilleure stratégie lors des élections groupées. Redis3.0 commence à prendre en charge les clusters.

En général, pour qu'un cluster parvienne à un consensus sur un certain état public, plus de la moitié des instances Redis du cluster doivent être d'accord.
Pourquoi avons-nous besoin d'une majorité ? Parce que nous devons considérer la situation de division du cerveau dans le cluster, c'est-à-dire la partition du réseau.
Une majorité peut garantir que, quelle que soit la manière dont le réseau est isolé, peu importe. comment est le cerveau Quel que soit le nombre de petits clusters dans lesquels le grand cluster est isolé, au moins une instance du petit cluster qui peut fournir des services (ce qui signifie qu'il y a plus de la moitié des instances) est synchronisée avec les dernières informations d'état.

Après avoir compris la majorité mentionnée ci-dessus, nous avons alors le contexte pour parler de pourquoi il s'agit d'un nombre impair
Les nombres pairs peuvent également avoir une majorité, par exemple, 4 Pour un groupe d'instances, 3 est une majorité.
Mais pourquoi les nombres impairs sont-ils toujours les meilleurs ?
Si le cluster possède 5 instances, il ne peut tolérer le crash que de 2 instances.
S'il y a 6 instances dans le cluster, il ne peut tolérer le crash que de 2 instances.
À même tolérance, quelle est la différence entre 6 et 5 :

• Étant donné que les clusters doivent communiquer entre eux, plus il y a d'instances, plus la surcharge du réseau est importante

• Plus il y a d'instances, lorsqu'il y a 5 instances, la probabilité de crash de 3 instances est moindre que lorsqu'il y a 6 instances.

Alors bien sûr, les nombres impairs sont les plus rentables.

C'est possible, il suffit de définir différents ports. Quant à l'impact, je ne pense pas que cela ait un impact particulier.

S'il y a 3 machines, chacune exécutera un maître, puis placera ses esclaves respectifs sur différentes machines pour former une sauvegarde en anneau, au lieu de mettre les œufs dans le même panier.
Si vous disposez de suffisamment de ressources IP, trouvez un middleware ha pour implémenter la haute disponibilité.

Il n'est pas recommandé de mettre l'environnement de production sur la même machine physique. Le cluster avec 3 maîtres parle d'un cluster 3.0. Un nombre impair de nœuds garantit que le vote peut produire un résultat défini

Eh bien, mettons l’esclave ailleurs.

Que pensez-vous de ce design ?