Redis Sentinel

Redis Sentinel er den officielle anbefaling for at køre en meget tilgængelig Redis-konfiguration ved at køre en række yderligere redis sentinel-processer for aktivt at overvåge eksisterende redis master- og slave-instanser og sikre, at de hver især fungerer som forventet. Hvis det ved konsensus bestemmes, at masteren ikke længere er tilgængelig, vil den automatisk failover og fremme en af ​​de replikerede slaver som den nye master. Sentinelerne opretholder også en autoritativ liste over tilgængelige redis-forekomster, som giver kunderne et centralt lager til at opdage tilgængelige forekomster, de kan oprette forbindelse til.

Support til Redis Sentinel er tilgængelig med RedisSentinel klasse, som lytter til de tilgængelige Sentinels for at hente sin liste over tilgængelige master-, slave- og andre sentinel redis-instanser, som den bruger til at konfigurere og vedligeholde Redis Client Managers, og initiere eventuelle failovers, efterhånden som de rapporteres.

Anvendelse #

For at bruge den nye Sentinel-understøttelse ville du i stedet for at udfylde Redis Client Managers med forbindelsesstrengen for master- og slave-forekomsterne oprette en enkelt RedisSentinel instans konfigureret med forbindelsesstrengen for de kørende Redis Sentinels:

var sentinelHosts = new[]{ "sentinel1", "sentinel2:6390", "sentinel3" };
var sentinel = new RedisSentinel(sentinelHosts, masterName: "mymaster");

Dette viser et typisk eksempel på konfiguration af en RedisSentinel som refererer til 3 sentinel-værter (dvs. minimumsantallet for en meget tilgængelig opsætning, som kan overleve enhver knudefejl). Den er også konfigureret til at se på mymaster konfigurationssæt (standardmastergruppen).

INFO

Redis Sentinels kan overvåge mere end 1 master/slave-gruppe, hver med et forskelligt mastergruppenavn.

Standardporten for vagtposter er 26379 (når det er uspecificeret), og da RedisSentinel automatisk kan opdage andre vagtposter, er den krævede minimumskonfiguration kun:

var sentinel = new RedisSentinel("sentinel1");

INFO

Scanning og automatisk opdagelse af andre Sentinels kan deaktiveres med ScanForOtherSentinels=false

Begynd at overvåge Sentinels #

Når den er konfigureret, kan du begynde at overvåge Redis Sentinel-serverne og få adgang til den forudkonfigurerede klientadministrator med:

IRedisClientsManager redisManager = sentinel.Start();

Som som før kan registreres i din foretrukne IOC som en singleton eksempel:

container.Register<IRedisClientsManager>(c => sentinel.Start());

Avanceret Sentinel-konfiguration #

RedisSentinel administrerer som standard en konfigureret PooledRedisClientManager instans, som løser begge Redis-master-klienter til læse/skrive GetClient() og slaver for skrivebeskyttet GetReadOnlyClient() API'er.

Dette kan ændres til at bruge den nyere RedisManagerPool med:

sentinel.RedisManagerFactory = (master,slaves) => new RedisManagerPool(master);

Tilpasset Redis-forbindelsesstreng #

Den vært, som RedisSentinel er konfigureret med, gælder kun for den Sentinel-vært, du kan stadig bruge fleksibiliteten i Redis Connection Strings til at konfigurere de individuelle Redis-klienter ved at angive et brugerdefineret HostFilter :

sentinel.HostFilter = host => "{0}?db=1&RetryTimeout=5000".Fmt(host);

Dette vil returnere klienter, der er konfigureret til at bruge Database 1 og en Timeout for Genforsøg på 5 sekunder (brugt i den nye funktion for automatisk forsøg).

Anden RedisSentinel-konfiguration #

Selvom ovenstående dækker den populære Sentinel-konfiguration, der typisk ville blive brugt, er næsten alle aspekter af RedisSentinel adfærd kan tilpasses med nedenstående konfiguration:

Konfigurer Redis Sentinel-servere #

Redis config-projektet forenkler opsætning og kørsel af en meget tilgængelig Redis Sentinel-konfiguration med flere noder inklusive start/stop-scripts til øjeblikkelig opsætning af den minimale højst tilgængelige Redis Sentinel-konfiguration på en enkelt (eller flere) Windows-, OSX- eller Linux-servere. Denne enkelt-server/multi-proces-konfiguration er ideel til opsætning af en fungerende sentinel-konfiguration på en enkelt dev-arbejdsstation eller fjernserver.

Redis-config repository inkluderer også MS OpenTech Windows redis binære filer og kræver ingen softwareinstallation.

Windows-brug #

For at køre den inkluderede Sentinel-konfiguration skal du klone redis-config-repoen på den server, du vil køre den på:

git clone https://github.com/ServiceStack/redis-config.git

Start derefter 1x Master, 2x Slaves og 3x Sentinel redis-servere med:

cd redis-config\sentinel3\windows
start-all.cmd

Nedlukningsstartede tilfælde:

stop-all.cmd

Hvis du kører redis-processerne lokalt på din dev-arbejdsstation, er den minimale konfiguration for at oprette forbindelse til de kørende forekomster bare:

var sentinel = new RedisSentinel("127.0.0.1:26380");
container.Register(c => sentinel.Start());

Localhost vs netværks-IP'er #

Sentinel-konfigurationen antager, at alle redis-forekomster kører lokalt på 127.0.0.1 . Hvis du i stedet kører det på en ekstern server, som du ønsker, at alle udviklere i dit netværk skal have adgang til, skal du enten ændre IP-adressen i *.conf filer for at bruge serverens netværks-IP. Ellers kan du forlade standardindstillingerne og bruge RedisSentinel IP-adressekortfunktion til transparent kortlægning af lokale værts-IP'er til den netværks-IP, som hver pc på dit netværk kan oprette forbindelse til.

For eksempel. hvis dette kører på en fjernserver med en 10.0.0.9 Netværks-IP, den kan konfigureres med:

var sentinel = new RedisSentinel("10.0.0.9:26380") {
    IpAddressMap = {
        {"127.0.0.1", "10.0.0.9"},
    }
};
container.Register(c => sentinel.Start());

Google Cloud - Klik for at implementere Redis #

Den nemmeste cloud-tjeneste, vi har fundet, som øjeblikkeligt kan konfigurere en multi-node-Redis Sentinel-konfiguration, er at bruge Google Clouds klik for at implementere Redis-funktion, der er tilgængelig fra Google Cloud Console under Deploy &Manage :

Klik på Implementer knappen giver dig mulighed for at konfigurere typen, størrelsen og placeringen, hvor du vil installere Redis VM'erne. Se den fulde Click to Deploy Redis-guide for en gennemgang af opsætning og inspektion af en meget tilgængelig redis-konfiguration på Google Cloud.

Skift for at bruge RedisManagerPool #

Som standard bruger RedisSentinel en PooledRedisClientManager , kan dette ændres til at bruge den nyere RedisManagerPool med:

sentinel.RedisManagerFactory = (master,replicas) => new RedisManagerPool(master);

Begynd at overvåge Sentinels #

Når den er konfigureret, kan du begynde at overvåge Redis Sentinel-serverne og få adgang til den forudkonfigurerede klientadministrator med:

IRedisClientsManager redisManager = sentinel.Start();

Som som før kan registreres i din foretrukne IOC som en singleton eksempel:

container.Register<IRedisClientsManager>(c => sentinel.Start());

Konfigurer Redis Sentinel-servere #

Se redis config-projektet for en hurtig måde at konfigurere den minimale, højst tilgængelige Redis Sentinel-konfiguration inklusive start/stop-scripts til øjeblikkeligt at køre flere redis-forekomster på en enkelt (eller flere) Windows-, OSX- eller Linux-servere.

Redis-statistik #

Du kan bruge RedisStats klasse for synlighed og introspektion i dine løbeforekomster. Redis Stats-wikien viser den tilgængelige statistik.

Automatiske genforsøg #

For at forbedre modstandsdygtigheden af ​​klientforbindelser, RedisClient vil gennemsigtigt gentage mislykkede Redis-operationer på grund af Socket- og I/O-undtagelser i en eksponentiel backoff startende fra 10ms indtil RetryTimeout af 10.000 ms . Disse standardindstillinger kan justeres med:

RedisConfig.DefaultRetryTimeout = 10000;
RedisConfig.BackOffMultiplier = 10;