Jeg var i stand til at bruge lidt tid i sidste uge med Linux-fyrene på at teste scenarier og arbejde på C#-siden af denne implementering og bruger følgende tilgang:
- Læs sentinel-adresserne fra config og opret en ConnectionMultiplexer for at oprette forbindelse til dem
- Abonner på +switch-master-kanalen
- Spørg hver enkelt vagtserver efter tur, hvad de tror, master redis og slaver er, sammenlign dem alle for at sikre, at de alle er enige
- Opret en ny ConnectionMultiplexer med redis-serveradresserne læst fra sentinel og tilslut, tilføj hændelseshandler til ConnectionFailed og ConnectionRestored.
- Når jeg modtager +switch-master-meddelelsen, kalder jeg Configure() på redis ConnectionMultiplexer
- Som et bælte og seler nærmer sig, ringer jeg altid til Configure() på redis ConnectionMultiplexer 12 sekunder efter at have modtaget en forbindelsesfejl eller forbindelsesgendannet hændelse, når forbindelsestypen er ConnectionType.Interactive.
Jeg oplever, at jeg generelt arbejder og omkonfigurerede efter ca. 5 sekunder efter at have mistet redis-masteren. I løbet af denne tid kan jeg ikke skrive, men jeg kan læse (da man kan læse en slave af). 5 sekunder er ok for os, da vores data opdateres meget hurtigt og bliver forældet efter et par sekunder (og efterfølgende overskrives).
En ting, jeg ikke var sikker på, var, om jeg skulle fjerne redis-serveren fra redis ConnectionMultiplexer, når en instans går ned, eller lade den fortsætte med at prøve forbindelsen igen. Jeg besluttede at lade den prøve igen, da den kommer tilbage i blandingen som slave, så snart den kommer op igen. Jeg foretog nogle præstationstest med og uden en forbindelse, der blev prøvet igen, og det så ud til at gøre lidt forskel. Måske kan nogen afklare, om dette er den rigtige tilgang.
En gang imellem at bringe en instans tilbage, der tidligere var en mester, så ud til at forårsage en vis forvirring - et par sekunder efter, at den kom op igen, ville jeg modtage en undtagelse fra at skrive - "KUN LÆSE", hvilket tyder på, at jeg ikke kan skrive til en slave. Dette var sjældent, men jeg fandt ud af, at min "catch-all"-tilgang med at kalde Configure() 12 sekunder efter en forbindelsestilstandsændring fangede dette problem. At kalde Configure() virker meget billigt, og derfor virkede det OK at kalde det to gange, uanset om det var nødvendigt eller ej.
Nu hvor jeg har slaver, har jeg aflastet noget af min dataoprydningskode, som laver nøglescanninger til slaverne, hvilket gør mig glad.
Alt i alt er jeg ret tilfreds, det er ikke perfekt, men til noget, der meget sjældent skulle ske, er det mere end godt nok.