Pude passar algum tempo na semana passada com os caras do Linux testando cenários e trabalhando no lado C# dessa implementação e estou usando a seguinte abordagem:

• Leia os endereços sentinela da configuração e crie um ConnectionMultiplexer para se conectar a eles
• Inscreva-se no canal +switch-master
• Pergunte a cada servidor sentinela o que eles acham que são os mestres redis e os escravos, compare-os para ter certeza de que todos concordam
• Crie um novo ConnectionMultiplexer com os endereços do servidor redis lidos do sentinela e conecte-se, adicione o manipulador de eventos a ConnectionFailed e ConnectionRestored.
• Quando recebo a mensagem +switch-master, chamo Configure() no redis ConnectionMultiplexer
• Como uma abordagem de cinto e chaves, eu sempre chamo Configure() no redis ConnectionMultiplexer 12 segundos depois de receber um evento connectionFailed ou connectionRestored quando o tipo de conexão é ConnectionType.Interactive.

Acho que geralmente estou trabalhando e reconfigurado após cerca de 5 segundos perdendo o mestre redis. Durante este tempo eu não posso escrever, mas posso ler (já que você pode ler um escravo). 5 segundos é bom para nós, pois nossos dados são atualizados muito rapidamente e ficam obsoletos após alguns segundos (e posteriormente são substituídos).

Uma coisa que eu não tinha certeza era se eu deveria ou não remover o servidor redis do redis ConnectionMultiplexer quando uma instância fica inativa ou deixá-lo continuar tentando novamente a conexão. Decidi deixá-lo tentando novamente, pois ele volta à mixagem como escravo assim que volta. Fiz alguns testes de desempenho com e sem uma nova tentativa de conexão e pareceu fazer pouca diferença. Talvez alguém possa esclarecer se esta é a abordagem correta.

De vez em quando, trazer de volta uma instância que anteriormente era um mestre parecia causar alguma confusão - alguns segundos depois de voltar, eu receberia uma exceção ao escrever - "READONLY" sugerindo que não posso escrever para um escravo. Isso era raro, mas descobri que minha abordagem "pega-tudo" de chamar Configure() 12 segundos após uma mudança de estado de conexão detectou esse problema. Chamar Configure() parece muito barato e, portanto, chamá-lo duas vezes, independentemente de ser ou não necessário, parecia OK.

Agora que tenho escravos, descarreguei alguns dos meus códigos de limpeza de dados que fazem varreduras de chave para os escravos, o que me deixa feliz.

No geral estou bastante satisfeito, não é perfeito, mas para algo que deve acontecer muito raramente é mais do que suficiente.