Ik kon vorige week wat tijd doorbrengen met de Linux-jongens om scenario's te testen en aan de C#-kant van deze implementatie te werken en ik gebruik de volgende aanpak:
- Lees de schildwachtadressen uit de configuratie en maak een ConnectionMultiplexer om er verbinding mee te maken
- Abonneer je op het +switch-master-kanaal
- Vraag elke schildwachtserver om de beurt wat zij denken dat de master redis en slaves zijn, vergelijk ze allemaal om er zeker van te zijn dat ze het allemaal eens zijn
- Maak een nieuwe ConnectionMultiplexer met de redis-serveradressen die zijn gelezen van sentinel en maak verbinding, voeg gebeurtenishandler toe aan ConnectionFailed en ConnectionRestored.
- Als ik het bericht +switch-master ontvang, bel ik Configure() op de redis ConnectionMultiplexer
- Als een riem en beugelbenadering roep ik altijd Configure() op de redis ConnectionMultiplexer 12 seconden na ontvangst van een connectionFailed of connectionRestored-gebeurtenis wanneer het verbindingstype ConnectionType.Interactive is.
Ik merk dat ik over het algemeen aan het werk ben en opnieuw geconfigureerd na ongeveer 5 seconden nadat ik de redis-master kwijt ben. Gedurende deze tijd kan ik niet schrijven maar wel lezen (aangezien je een slaaf kunt aflezen). 5 seconden is oké voor ons omdat onze gegevens zeer snel worden bijgewerkt en na een paar seconden oud worden (en vervolgens worden overschreven).
Een ding waar ik niet zeker van was, was of ik de redis-server al dan niet van de redis ConnectionMultiplexer moest verwijderen wanneer een instance uitvalt, of dat ik hem de verbinding opnieuw moet laten proberen. Ik besloot het opnieuw te proberen, want het komt terug in de mix als een slaaf zodra het weer opkomt. Ik heb wat prestatietests gedaan met en zonder dat een verbinding opnieuw werd geprobeerd en het leek weinig verschil te maken. Misschien kan iemand verduidelijken of dit de juiste aanpak is.
Zo nu en dan het terugbrengen van een instantie die voorheen een master was, leek enige verwarring te veroorzaken - een paar seconden nadat het weer opkwam, kreeg ik een uitzondering van schrijven - "LEES ALLEEN" wat suggereert dat ik niet naar een slaaf kan schrijven. Dit was zeldzaam, maar ik ontdekte dat mijn "catch-all" -benadering van het aanroepen van Configure() 12 seconden na een wijziging van de verbindingsstatus dit probleem opving. Het aanroepen van Configure() lijkt erg goedkoop en daarom lijkt het goed om het twee keer te bellen, ongeacht of het nodig is of niet.
Nu ik slaven heb, heb ik een deel van mijn code voor het opschonen van gegevens verwijderd die sleutelscans naar de slaven doet, wat me blij maakt.
Al met al ben ik redelijk tevreden, het is niet perfect, maar voor iets dat heel zelden zou moeten gebeuren, is het meer dan goed genoeg.