Pude pasar un tiempo la semana pasada con los muchachos de Linux probando escenarios y trabajando en el lado C# de esta implementación y estoy usando el siguiente enfoque:
- Lea las direcciones centinela de la configuración y cree un ConnectionMultiplexer para conectarse a ellas
- Suscríbete al canal +switch-master
- Pregunte a cada servidor centinela por turnos qué creen que son los redis maestros y los esclavos, compárelos todos para asegurarse de que todos estén de acuerdo
- Cree un nuevo ConnectionMultiplexer con las direcciones del servidor Redis leídas de Sentinel y conecte, agregue el controlador de eventos a ConnectionFailed y ConnectionRestored.
- Cuando recibo el mensaje +switch-master llamo a Configure() en el ConnectionMultiplexer de redis
- Como un enfoque de cinturón y llaves, siempre llamo Configure() en el redis ConnectionMultiplexer 12 segundos después de recibir un evento de conexión fallida o conexión restaurada cuando el tipo de conexión es ConnectionType.Interactive.
Encuentro que, en general, estoy trabajando y reconfigurado después de unos 5 segundos de perder el maestro redis. Durante este tiempo no puedo escribir pero puedo leer (ya que puedes leer un esclavo). 5 segundos está bien para nosotros, ya que nuestros datos se actualizan muy rápidamente y se vuelven obsoletos después de unos segundos (y posteriormente se sobrescriben).
Una cosa de la que no estaba seguro era si debía eliminar o no el servidor redis de redis ConnectionMultiplexer cuando una instancia deja de funcionar, o dejar que continuara reintentando la conexión. Decidí dejarlo reintentando, ya que vuelve a la mezcla como esclavo tan pronto como vuelve a aparecer. Hice algunas pruebas de rendimiento con y sin reintento de conexión y pareció hacer poca diferencia. Tal vez alguien pueda aclarar si este es el enfoque correcto.
De vez en cuando, traer de vuelta una instancia que anteriormente era un maestro parecía causar cierta confusión:unos segundos después de que volvía a aparecer, recibía una excepción de escritura:"READONLY" que sugiere que no puedo escribir a un esclavo. Esto era raro, pero descubrí que mi enfoque "catch-all" de llamar a Configure () 12 segundos después de un cambio de estado de conexión detectó este problema. Llamar a Configure() parece muy barato y, por lo tanto, llamarlo dos veces, independientemente de si es necesario o no, parecía correcto.
Ahora que tengo esclavos, he descargado parte de mi código de limpieza de datos que escanea las claves de los esclavos, lo que me hace feliz.
En general, estoy bastante satisfecho, no es perfecto, pero para algo que rara vez sucede, es más que suficiente.
