J'ai pu passer du temps la semaine dernière avec les gars de Linux pour tester des scénarios et travailler sur le côté C# de cette implémentation et j'utilise l'approche suivante :
- Lire les adresses sentinelles de la configuration et créer un ConnectionMultiplexer pour s'y connecter
- Abonnez-vous à la chaîne +switch-master
- Demandez tour à tour à chaque serveur sentinelle ce qu'il pense que le redis maître et les esclaves sont, comparez-les tous pour vous assurer qu'ils sont tous d'accord
- Créez un nouveau ConnectionMultiplexer avec les adresses de serveur Redis lues à partir de la sentinelle et connectez-vous, ajoutez le gestionnaire d'événements à ConnectionFailed et ConnectionRestored.
- Lorsque je reçois le message + switch-master, j'appelle Configure() sur le Redis ConnectionMultiplexer
- En tant qu'approche ceinture et accolades, j'appelle toujours Configure() sur le Redis ConnectionMultiplexer 12 secondes après avoir reçu un événement connectionFailed ou connectionRestored lorsque le type de connexion est ConnectionType.Interactive.
Je trouve que généralement je travaille et que je reconfigure après environ 5 secondes de perte du maître redis. Pendant ce temps, je ne peux pas écrire mais je peux lire (puisque vous pouvez lire un esclave). 5 secondes nous conviennent car nos données sont mises à jour très rapidement et deviennent obsolètes après quelques secondes (et sont ensuite écrasées).
Une chose dont je n'étais pas sûr était de savoir si je devais ou non supprimer le serveur redis du Redis ConnectionMultiplexer lorsqu'une instance tombait en panne, ou le laisser continuer à réessayer la connexion. J'ai décidé de le laisser réessayer car il revient dans le mix en tant qu'esclave dès qu'il revient. J'ai fait quelques tests de performance avec et sans nouvelle tentative de connexion et cela semblait faire peu de différence. Peut-être que quelqu'un peut clarifier si c'est la bonne approche.
De temps en temps, ramener une instance qui était auparavant un maître semblait semer la confusion - quelques secondes après sa réapparition, je recevais une exception d'écriture - "READONLY" suggérant que je ne peux pas écrire sur un esclave. C'était rare mais j'ai trouvé que mon approche "fourre-tout" consistant à appeler Configure() 12 secondes après un changement d'état de connexion a détecté ce problème. Appeler Configure() semble très bon marché et donc l'appeler deux fois, que ce soit nécessaire ou non, semblait correct.
Maintenant que j'ai des esclaves, j'ai déchargé une partie de mon code de nettoyage de données qui effectue des analyses de clé sur les esclaves, ce qui me rend heureux.
Dans l'ensemble, je suis assez satisfait, ce n'est pas parfait mais pour quelque chose qui devrait arriver très rarement, c'est plus que suffisant.
