sql >> Databáze >  >> NoSQL >> Redis

Redis failover s StackExchange / Sentinel z C#

Minulý týden jsem mohl strávit nějaký čas s lidmi z Linuxu testováním scénářů a prací na straně C# této implementace a používám následující přístup:

  • Přečtěte si adresy hlídačů z konfigurace a vytvořte ConnectionMultiplexer, abyste se k nim mohli připojit
  • Přihlaste se k odběru kanálu +switch-master
  • Postupně se zeptejte každého strážného serveru, co si myslí, že jsou hlavní redis a otroci, porovnejte je všechny, abyste se ujistili, že všichni souhlasí.
  • Vytvořte nový ConnectionMultiplexer s adresami serveru redis načtenými z sentinelu a připojte se, přidejte obsluhu události do ConnectionFailed a ConnectionRestored.
  • Když obdržím zprávu +switch-master, zavolám Configure() na redis ConnectionMultiplexer
  • Jakmile se blíží pás a rovnátka, vždy volám Configure() na redis ConnectionMultiplexer 12 sekund po přijetí události connectionFailed nebo connectionRestored, když je typ připojení ConnectionType.Interactive.

Zjistil jsem, že obecně pracuji a překonfiguruji po asi 5 sekundách ztráty redis master. Během této doby neumím psát, ale umím číst (protože můžete číst z otroka). 5 sekund je pro nás v pořádku, protože naše data se velmi rychle aktualizují a po několika sekundách se zastarají (a následně se přepíší).

Jedna věc, kterou jsem si nebyl jistý, bylo, zda mám nebo nemám odebrat server redis z redis ConnectionMultiplexer, když instance selže, nebo jej nechat pokračovat v pokusu o připojení. Rozhodl jsem se, že to nechám opakovat, protože se to vrátí do mixu jako otrok, jakmile se to vrátí. Provedl jsem nějaké testování výkonu s opakovaným pokusem o připojení a bez něj a zdálo se, že to nemá žádný rozdíl. Možná někdo objasní, zda je to správný přístup.

Tu a tam se zdálo, že přivedení zpět instance, která byla dříve hlavní, způsobovalo zmatek - několik sekund poté, co se vrátila, jsem obdržel výjimku ze zápisu - "POUZE PRO ČTENÍ", což naznačuje, že nemohu zapisovat na slave. To bylo vzácné, ale zjistil jsem, že můj „catch-all“ přístup volání Configure() 12 sekund po změně stavu připojení zachytil tento problém. Volání Configure() se zdá být velmi levné, a proto se zdálo být jeho volání dvakrát bez ohledu na to, zda je to nutné, či nikoli.

Nyní, když mám otroky, stáhl jsem část svého kódu pro čištění dat, který provádí skenování klíčů u otroků, což mě těší.

Celkově jsem docela spokojený, není to dokonalé, ale na něco, co by se mělo stát jen velmi zřídka, je to víc než dost dobré.



  1. Výhody a nevýhody použití celeru vs. RQ

  2. Nastavení dynamického pole v Ohm / Redis

  3. Používáte Redis k implementaci přihlášení?

  4. Připojte řetězec na konec existujícího pole v MongoDB