Jag kunde spendera lite tid förra veckan med Linux-killarna på att testa scenarier och arbeta på C#-sidan av denna implementering och använder följande tillvägagångssätt:
- Läs sentineladresserna från config och skapa en ConnectionMultiplexer för att ansluta till dem
- Prenumerera på +switch-master-kanalen
- Fråga varje sentinel-server i tur och ordning vad de tror att master redis och slavar är, jämför dem alla för att se till att de alla håller med
- Skapa en ny ConnectionMultiplexer med redis-serveradresserna som läses från sentinel och anslut, lägg till händelsehanterare till ConnectionFailed och ConnectionRestored.
- När jag får +switch-master-meddelandet anropar jag Configure() på redis ConnectionMultiplexer
- Som ett bälte och hängslen närmar sig anropar jag alltid Configure() på redis ConnectionMultiplexer 12 sekunder efter att jag tagit emot en connectionFailed eller connectionRestored-händelse när anslutningstypen är ConnectionType.Interactive.
Jag upptäcker att jag i allmänhet arbetar och konfigurerade om efter cirka 5 sekunder efter att jag tappade redis-mastern. Under den här tiden kan jag inte skriva men jag kan läsa (eftersom man kan läsa av en slav). 5 sekunder är ok för oss eftersom vår data uppdateras mycket snabbt och blir inaktuell efter några sekunder (och skrivs sedan över).
En sak som jag inte var säker på var om jag skulle ta bort redis-servern från redis ConnectionMultiplexer när en instans går ner, eller låta den fortsätta att försöka ansluta igen. Jag bestämde mig för att låta den försöka igen eftersom den kommer tillbaka in i mixen som slav så fort den kommer upp igen. Jag gjorde en del prestandatester med och utan att en anslutning prövades igen och det verkade göra liten skillnad. Kanske kan någon klargöra om detta är rätt tillvägagångssätt.
Att då och då ta tillbaka en instans som tidigare var en mästare verkade orsaka viss förvirring - några sekunder efter att den kom tillbaka fick jag ett undantag från att skriva - "LÄSONLY" som tyder på att jag inte kan skriva till en slav. Detta var sällsynt men jag upptäckte att min "catch-all"-metod att anropa Configure() 12 sekunder efter en ändring av anslutningstillstånd fångade detta problem. Att anropa Configure() verkar väldigt billigt och därför verkade det OK att anropa det två gånger oavsett om det var nödvändigt eller inte.
Nu när jag har slavar har jag laddat bort en del av min datarensningskod som gör nyckelskanningar till slavarna, vilket gör mig glad.
Allt som allt är jag ganska nöjd, det är inte perfekt men för något som väldigt sällan skulle hända är det mer än bra nog.