Ich konnte letzte Woche einige Zeit mit den Linux-Leuten verbringen, um Szenarien zu testen und an der C#-Seite dieser Implementierung zu arbeiten, und verwende den folgenden Ansatz:
- Lesen Sie die Sentinel-Adressen aus der Konfiguration und erstellen Sie einen ConnectionMultiplexer, um sich mit ihnen zu verbinden
- Abonnieren Sie den +Switch-Master-Kanal
- Fragen Sie nacheinander jeden Sentinel-Server, was seiner Meinung nach die Master-Redis und Slaves sind, vergleichen Sie sie alle, um sicherzustellen, dass sie alle übereinstimmen
- Erstellen Sie einen neuen ConnectionMultiplexer mit den aus Sentinel gelesenen Redis-Serveradressen und verbinden Sie sich, fügen Sie ConnectionFailed und ConnectionRestored einen Ereignishandler hinzu.
- Wenn ich die Nachricht +switch-master erhalte, rufe ich Configure() auf dem redis ConnectionMultiplexer auf
- Als Gürtel-und-Hosenträger-Ansatz rufe ich Configure() auf dem redis ConnectionMultiplexer immer 12 Sekunden nach Erhalt eines connectionFailed- oder connectionRestored-Ereignisses auf, wenn der Verbindungstyp ConnectionType.Interactive ist.
Ich finde, dass ich im Allgemeinen nach etwa 5 Sekunden nach dem Verlust des Redis-Masters arbeite und neu konfiguriere. Während dieser Zeit kann ich nicht schreiben, aber ich kann lesen (da man einen Sklaven ablesen kann). 5 Sekunden sind für uns in Ordnung, da unsere Daten sehr schnell aktualisiert werden und nach einigen Sekunden veraltet sind (und anschließend überschrieben werden).
Eine Sache, bei der ich mir nicht sicher war, war, ob ich den Redis-Server aus dem Redis ConnectionMultiplexer entfernen sollte, wenn eine Instanz ausfällt, oder ob ich die Verbindung weiterhin versuchen sollte. Ich beschloss, es erneut zu versuchen, da es als Sklave in den Mix zurückkehrt, sobald es wieder auftaucht. Ich habe einige Leistungstests mit und ohne erneuten Verbindungsversuch durchgeführt, und es schien kaum einen Unterschied zu machen. Vielleicht kann jemand klären, ob das der richtige Ansatz ist.
Hin und wieder schien das Zurückbringen einer Instanz, die zuvor ein Master war, einige Verwirrung zu stiften - ein paar Sekunden, nachdem sie wieder hochgefahren war, erhielt ich eine Ausnahme vom Schreiben - "READONLY", was darauf hindeutete, dass ich nicht an einen Slave schreiben kann. Dies kam selten vor, aber ich stellte fest, dass mein „Catch-all“-Ansatz, Configure() 12 Sekunden nach einer Änderung des Verbindungsstatus aufzurufen, dieses Problem auffing. Das Aufrufen von Configure() scheint sehr billig zu sein, und daher schien es in Ordnung zu sein, es zweimal aufzurufen, unabhängig davon, ob es notwendig ist oder nicht.
Jetzt, wo ich Sklaven habe, habe ich einen Teil meines Datenbereinigungscodes ausgelagert, der Schlüsselscans an die Sklaven durchführt, was mich glücklich macht.
Alles in allem bin ich ziemlich zufrieden, es ist nicht perfekt, aber für etwas, das sehr selten vorkommen sollte, ist es mehr als gut genug.
