Skala en Azure Cache for Redis-instans
Azure Cache for Redis har olika nivåerbjudanden som ger flexibilitet i valet av cachestorlek och funktioner. Genom skalning kan du ändra storlek, nivå och antal noder när du har skapat en cacheinstans så att den matchar dina programbehov. Den här artikeln visar hur du skalar cachen med hjälp av Azure Portal, plus verktyg som Azure PowerShell och Azure CLI.
Typer av skalning
Det finns i grunden två sätt att skala en Azure Cache for Redis-instans:
Uppskalning ökar storleken på den virtuella datorn (VM) som kör Redis-servern, lägger till mer minne, virtuella processorer (vCPU:er) och nätverksbandbredd. Uppskalning kallas även för lodrät skalning. Motsatsen till att skala upp är Att skala ned.
Genom att skala ut delas cacheinstansen in i fler noder av samma storlek, vilket ökar minne, vCPU:er och nätverksbandbredd genom parallellisering. Utskalning kallas även horisontell skalning eller horisontell partitionering. Motsatsen till utskalning är Att skala in. I Redis-communityn kallas utskalning ofta för klustring.
Tillgänglighetsomfång
Nivå | Basic och Standard | Premium | Enterprise och Enterprise Flash |
---|---|---|---|
Skala upp | Ja | Ja | Ja |
Skala ned | Ja | Ja | Nej |
Skala ut | Nej | Ja | Ja |
Skala in | Nej | Ja | Nej |
När ska du skala
Du kan använda övervakningsfunktionerna i Azure Cache for Redis för att övervaka hälsotillståndet och prestandan för din cache. Använd den informationen för att avgöra när cacheminnet ska skalas.
Du kan övervaka följande mått för att avgöra om du behöver skala.
- Redis-serverbelastning
- Hög Redis-serverbelastning innebär att servern inte kan hålla jämna steg med begäranden från alla klienter. Eftersom en Redis-server är en enda trådad process är det vanligtvis mer användbart att skala ut i stället för att skala upp. Genom att skala ut genom att aktivera klustring kan du distribuera overheadfunktioner mellan flera Redis-processer. Utskalning hjälper också till att distribuera TLS-kryptering/dekryptering och anslutning/frånkoppling, vilket påskyndar cacheinstanser med TLS.
- Att skala upp kan fortfarande vara användbart för att minska serverbelastningen eftersom bakgrundsaktiviteter kan dra nytta av de fler vCPU:er och frigöra tråden för redis-huvudserverprocessen.
- Enterprise- och Enterprise Flash-nivåerna använder Redis Enterprise i stället för öppen källkod Redis. En av fördelarna med dessa nivåer är att Redis-serverprocessen kan dra nytta av flera virtuella processorer. Med flera virtuella processorer kan både skalning och utskalning på dessa nivåer vara till hjälp för att minska serverbelastningen. Mer information finns i Metodtips för Enterprise- och Enterprise Flash-nivåerna i Azure Cache for Redis.
- Minnesanvändning
- Hög minnesanvändning anger att datastorleken är för stor för den aktuella cachestorleken. Överväg att skala till en cachestorlek med större minne. Att antingen skala upp eller skala ut är effektivt här.
- Klientanslutningar
- Varje cachestorlek har en gräns för antalet klientanslutningar som den kan stödja. Om klientanslutningarna ligger nära gränsen för cachestorleken bör du överväga att skala upp till en större nivå. Utskalning ökar inte antalet klientanslutningar som stöds.
- Mer information om anslutningsgränser efter cachestorlek finns i Prissättning för Azure Cache for Redis.
- Nätverksbandbredd
- Om Redis-servern överskrider den tillgängliga bandbredden kan klienternas begäranden överskrida tidsgränsen eftersom servern inte kan skicka data till klienten tillräckligt snabbt. Om du vill se hur mycket bandbredd på serversidan som används kontrollerar du måtten "Cacheläsning" och "Cacheskrivning". Om Redis-servern överskrider den tillgängliga nätverksbandbredden bör du överväga att skala ut eller skala upp till en större cachestorlek med högre nätverksbandbredd.
- För Enterprise-nivåcacheminnen med hjälp av enterprise-klusterprincipen ökar inte utskalning nätverksbandbredden.
- Mer information om nätverkstillgänglig bandbredd efter cachestorlek finns i Vanliga frågor och svar om Azure Cache for Redis-planering.
- Interna Defender-genomsökningar
- På C0 - och C1 Standard-cacheminnen, medan intern Defender-genomsökning körs på de virtuella datorerna, kan du se korta toppar i serverbelastningen som inte orsakas av en ökning av cachebegäranden. Du ser högre svarstid för begäranden medan interna Defender-genomsökningar körs på dessa nivåer ett par gånger om dagen. Cacheminnen på C0 - och C1-nivåerna har bara en enda kärna till multitask, vilket delar upp arbetet med att hantera interna Defender-genomsökningar och Redis-begäranden. Du kan minska effekten genom att skala till ett erbjudande på högre nivå med flera CPU-kärnor, till exempel C2.
- Den ökade cachestorleken på de högre nivåerna hjälper dig att åtgärda eventuella problem med svarstiden. På C2-nivå har du dessutom stöd för så många som 2 000 klientanslutningar.
Mer information om hur du bestämmer vilken cacheprisnivå som ska användas finns i Välja rätt nivå och Azure Cache for Redis planering vanliga frågor och svar.
Kommentar
Mer information om hur du optimerar skalningsprocessen finns i metodtipsen för skalning
Krav/begränsningar för skalning av Azure Cache for Redis
Du kan skala upp/ned till en annan prisnivå med följande begränsningar:
- Du kan inte skala från en högre prisnivå till en lägre prisnivå.
- Du kan inte skala från en Enterprise- eller Enterprise Flash-cache till någon annan nivå.
- Du kan inte skala från en Premium-cache till en Standard- eller Basic-cache.
- Du kan inte skala från en Standard-cache till en Basic-cache .
- Du kan skala från en Basic-cache till en Standard-cache , men du kan inte ändra storleken på samma gång. Om du behöver en annan storlek kan du senare utföra en skalningsåtgärd till önskad storlek.
- Du kan inte skala från en Basic-cache direkt till en Premium-cache . Skala först från Basic till Standard i en skalningsåtgärd och sedan från Standard till Premium i nästa skalningsåtgärd.
- Du kan inte skala från en större storlek till C0-storleken (250 MB). Du kan dock skala in till valfri annan storlek inom samma prisnivå. Du kan till exempel skala in från C5 Standard till C1 Standard.
- Du kan inte skala från en Premium-, Standard- eller Basic-cache upp till ett Enterprise- eller Enterprise Flash-cacheminne.
- Du kan inte skala mellan Enterprise och Enterprise Flash.
Du kan skala ut/in med följande begränsningar:
- Utskalning stöds endast på Premium-, Enterprise- och Enterprise Flash-nivåerna .
- Skalning i stöds endast på Premium-nivån .
- På Premium-nivån måste klustring aktiveras först innan du skalar in eller ut.
- På Premium-nivån är stöd för att skala ut upp till 10 shards allmänt tillgängligt. Stöd för upp till 30 shards finns i förhandsversionen. (För cacheminnen med två repliker är shardgränsen 20. Med tre repliker är shardgränsen 15.)
- Endast Enterprise- och Enterprise Flash-nivåerna kan skalas upp och skalas ut samtidigt.
Skala – nivåerna Basic, Standard och Premium
Skala upp och ut – Enterprise- och Enterprise Flash-nivåer
Enterprise- och Enterprise Flash-nivåerna kan skalas upp och skalas ut i en åtgärd. Andra nivåer kräver separata åtgärder för varje åtgärd.
Varning
Enterprise- och Enterprise Flash-nivåerna stöder ännu inte nedskalning eller skalning i åtgärder.
Skala med hjälp av Azure Portal
Om du vill skala cacheminnet bläddrar du till cachen i Azure Portal och väljer Skala på resursmenyn.
Om du vill skala upp väljer du en annan cachetyp och väljer sedan Spara.
Viktigt!
Du kan bara skala upp just nu. Du kan inte skala ned.
Öka skjutreglaget Kapacitet om du vill skala ut. Kapacitetsökningar i steg om två. Det här talet visar hur många underliggande Redis Enterprise-noder som läggs till. Det här talet är alltid en multipel av två för att återspegla noder som läggs till för både primära partitioner och replikskärvor.
Viktigt!
Du kan bara skala ut och öka kapaciteten just nu. Du kan inte skala in.
Medan cacheminnet skalas till den nya nivån visas ett meddelande om skalning av Redis Cache .
När skalningen är klar ändras statusen från Skalning till Körning.
Skala med PowerShell
Du kan skala dina Azure Cache for Redis-instanser med PowerShell med hjälp av cmdleten Update-AzRedisEnterpriseCache . Du kan ändra Sku
egenskapen för att skala upp instansen. Du kan ändra Capacity
egenskapen för att skala ut instansen. I följande exempel visas hur du skalar en cache med namnet myCache
till en Enterprise E20-instans (25 GB) med kapacitet på 4.
Update-AzRedisEnterpriseCache -ResourceGroupName myGroup -Name myCache -Sku Enterprise_E20 -Capacity 4
Skala med Hjälp av Azure CLI
Om du vill skala dina Azure Cache for Redis-instanser med Azure CLI anropar du kommandot az redisenterprise update . Du kan ändra sku
egenskapen för att skala upp instansen. Du kan ändra capacity
egenskapen för att skala ut instansen. I följande exempel visas hur du skalar en cache med namnet myCache
till en Enterprise E20-instans (25 GB) med kapacitet på 4.
az redisenterprise update --cluster-name "myCache" --resource-group "myGroup" --sku "Enterprise_E20" --capacity 4
Vanliga frågor och svar om skalning
Följande lista innehåller svar på vanliga frågor om Azure Cache for Redis-skalning.
- Kan jag skala till, från eller i en Premium-cache?
- Måste jag ändra cachenamnet eller åtkomstnycklarna efter skalningen?
- Hur fungerar skalning?
- Förlorar jag data från cacheminnet under skalningen?
- Kan jag använda alla funktioner på Premium-nivån efter skalning?
- Påverkas inställningen för anpassade databaser under skalningen?
- Kommer min cache att vara tillgänglig under skalning?
- Finns det skalningsbegränsningar med geo-replikering?
- Åtgärder som inte stöds
- Hur lång tid tar skalningen?
- Hur vet jag när skalningen är klar?
- Behöver jag göra några ändringar i mitt klientprogram för att använda klustring?
- Hur distribueras nycklar i ett kluster?
- Vilken är den största cachestorleken jag kan skapa?
- Stöder alla Redis-klienter klustring?
- Hur gör jag för att ansluta till min cache när klustring är aktiverat?
- Kan jag ansluta direkt till de enskilda fragmenten i min cache?
- Kan jag konfigurera klustring för en tidigare skapad cache?
- Kan jag konfigurera klustring för en grundläggande cache eller en standardcache?
- Kan jag använda klustring med Redis ASP.NET sessionstillstånd och cachelagring av utdata?
- Jag får MOVE-undantag när jag använder StackExchange.Redis och klustring, vad ska jag göra?
- Vad är skillnaden mellan OSS-klustring och Enterprise-klustring på enterprise-nivåcacheminnen?
- Hur många shards använder cacheminnen på Enterprise-nivå?
Kan jag skala till, från eller i en Premium-cache?
- Du kan inte skala från en Premium-cache ned till prisnivån Basic eller Standard .
- Du kan skala från en prisnivå för Premium Cache till en annan.
- Du kan inte skala från en Basic-cache direkt till en Premium-cache . Först skalar du från Basic till Standard i en skalningsåtgärd och sedan från Standard till Premium i en senare skalningsåtgärd.
- Du kan inte skala från en Premium-cache till ett Enterprise - eller Enterprise Flash-cacheminne .
- Om du aktiverade klustring när du skapade Premium-cachen kan du ändra klusterstorleken. Om cachen har skapats utan att klustring har aktiverats kan du konfigurera klustring vid ett senare tillfälle.
Måste jag ändra cachenamnet eller åtkomstnycklarna efter skalningen?
Nej, cachenamnet och nycklarna ändras inte under en skalningsåtgärd.
Hur fungerar skalning?
- När du skalar en Basic-cache till en annan storlek stängs cachen av och en ny cache etableras med den nya storleken. Under den här tiden är cachen inte tillgänglig och alla data i cacheminnet går förlorade.
- När du skalar en Basic-cache till en Standard-cache etableras en replikcache och data kopieras från den primära cachen till replikcachen. Cachen är fortfarande tillgänglig under skalningsprocessen.
- När du skalar en Standard-, Premium-, Enterprise- eller Enterprise Flash-cache till en annan storlek stängs en av replikerna av och ometableras till den nya storleken och de data som överförs över, och sedan gör den andra repliken en redundansväxling innan den återskapas, ungefär som den process som inträffar under ett fel i en av cachenoderna.
- När du skalar ut en klustrad cache etableras nya shards och läggs till i Redis-serverklustret. Data partitioneras sedan på nytt över alla shards.
- När du skalar i en klustrad cache partitioneras först data om och sedan minskas klusterstorleken till nödvändiga shards.
- I vissa fall, till exempel skalning eller migrering av cacheminnet till ett annat kluster, kan cachens underliggande IP-adress ändras. DNS-posten för cachen ändras och är transparent för de flesta program. Men om du använder en IP-adress för att konfigurera anslutningen till din cache, eller för att konfigurera NSG:er eller brandväggar som tillåter trafik till cachen, kan ditt program ha problem med att ansluta någon gång efter att DNS-postuppdateringarna har uppdaterats.
Förlorar jag data från cacheminnet under skalningen?
- När du skalar en Basic-cache till en ny storlek går alla data förlorade och cacheminnet är inte tillgängligt under skalningsåtgärden.
- När du skalar en Basic-cache till en Standard-cache bevaras vanligtvis data i cacheminnet.
- När du skalar en Standard-, Premium-, Enterprise- eller Enterprise Flash-cache till en större storlek bevaras vanligtvis alla data. När du skalar en Standard- eller Premium-cache till en mindre storlek kan data gå förlorade om datastorleken överskrider den nya mindre storleken när cachen skalas ned. Om data går förlorade vid nedskalning avlägsnas nycklar med hjälp av principen allkeys-lru-borttagning .
Kan jag använda alla funktioner på Premium-nivån efter skalning?
Nej, vissa funktioner kan bara anges när du skapar en cache på Premium-nivån och inte är tillgängliga efter skalning.
Det går inte att lägga till de här funktionerna när du har skapat Premium-cachen:
- Virtuell nätverksinmatning
- Lägga till zonredundans
- Använda flera repliker per primär
Om du vill använda någon av dessa funktioner måste du skapa en ny cacheinstans på Premium-nivån.
Påverkas inställningen för anpassade databaser under skalningen?
Om du konfigurerade ett anpassat värde för databases
inställningen när cacheminnet skapades bör du tänka på att vissa prisnivåer har olika databasgränser. Här följer några överväganden vid skalning i det här scenariot:
- När du skalar till en prisnivå med en lägre
databases
gräns än den aktuella nivån:- Om du använder standardnumret
databases
, vilket är 16 för alla prisnivåer, går inga data förlorade. - Om du använder ett anpassat antal
databases
som ligger inom gränserna för den nivå som du skalar till behålls den härdatabases
inställningen och inga data går förlorade. - Om du använder ett anpassat antal
databases
som överskrider gränserna för den nya nivåndatabases
sänks inställningen till den nya nivåns gränser och alla data i de borttagna databaserna går förlorade.
- Om du använder standardnumret
- När du skalar till en prisnivå med samma eller högre
databases
gräns än den aktuella nivån behålls inställningendatabases
och inga data går förlorade.
Standard-, Premium-, Enterprise- och Enterprise Flash-cacheminnen har ett serviceavtal för tillgänglighet, men det finns inget serviceavtal för dataförlust.
Kommer min cache att vara tillgänglig under skalning?
- Standard-, Premium-, Enterprise- och Enterprise Flash-cacheminnen förblir tillgängliga under skalningsåtgärden. Anslutningsblips kan dock ske vid skalning av dessa cacheminnen och även vid skalning från Basic till Standard-cacheminnen . Dessa anslutningsblips förväntas vara små och Redis-klienter kan vanligtvis återupprätta sin anslutning omedelbart.
- För Enterprise - och Enterprise Flash-cacheminnen med aktiv geo-replikering kan skalning av endast en delmängd länkade cacheminnen medföra problem över tid i vissa fall. Vi rekommenderar att du skalar alla cacheminnen i gruppen geo-replikering där det är möjligt.
- Grundläggande cacheminnen är offline under skalningsåtgärder till en annan storlek. Grundläggande cacheminnen är fortfarande tillgängliga vid skalning från Basic till Standard , men kan uppleva en liten anslutningsblip. Om en anslutningsblip inträffar kan Redis-klienter vanligtvis återupprätta sin anslutning omedelbart.
Finns det skalningsbegränsningar med geo-replikering?
När passiv geo-replikering har konfigurerats kanske du märker att du inte kan skala en cache eller ändra shards i ett kluster. En geo-replikeringslänk mellan två cacheminnen förhindrar att du skalar eller ändrar antalet shards i ett kluster. Du måste ta bort länken till cachen för att kunna utfärda dessa kommandon. Mer information finns i Konfigurera geo-replikering.
Med aktiv geo-replikering konfigurerad kan du inte skala en cache. Alla cacheminnen i en geo-replikeringsgrupp måste ha samma storlek och kapacitet.
Åtgärder som inte stöds
- Du kan inte skala från en högre prisnivå till en lägre prisnivå.
- Du kan inte skala från en Premium-cache till en Standard- eller Basic-cache.
- Du kan inte skala från en Standard-cache till en Basic-cache .
- Du kan skala från en Basic-cache till en Standard-cache , men du kan inte ändra storleken på samma gång. Om du behöver en annan storlek kan du utföra en skalningsåtgärd till önskad storlek vid ett senare tillfälle.
- Du kan inte skala från en Basic-cache direkt till en Premium-cache . Skala först från Basic till Standard i en skalningsåtgärd och skala sedan från Standard till Premium i en senare åtgärd.
- Du kan inte skala från en Premium-cache till ett Enterprise - eller Enterprise Flash-cacheminne .
- Du kan inte skala från en större storlek ned till storleken C0 (250 MB).
Om en skalningsåtgärd misslyckas försöker tjänsten återställa åtgärden och cacheminnet återgår till den ursprungliga storleken.
Hur lång tid tar skalningen?
Skalningstiden beror på några faktorer. Här följer några faktorer som kan påverka hur lång tid skalningen tar.
- Mängd data: Det tar längre tid att replikera större mängder data
- Höga skrivbegäranden: Högre antal skrivningar innebär att fler data replikeras mellan noder eller shards
- Hög serverbelastning: Högre serverbelastning innebär att Redis-servern är upptagen och att begränsade CPU-cykler är tillgängliga för att slutföra datadistributionen
Att skala en cache är en icke-trivial åtgärd och kan ta lång tid.
Baserat på verkliga exempel kan tiden för att skala cache med en till två shards vara 1 till 2 timmar när cachen inte är under tung belastning. Om du har fler shards ökar inte tiden för skalning på ett linjärt sätt.
Hur vet jag när skalningen är klar?
I Azure Portal kan du se skalningsåtgärden pågår. När skalningen är klar ändras statusen för cacheminnet till Körs.
Behöver jag göra några ändringar i mitt klientprogram för att använda klustring?
När klustring är aktiverat är endast databas 0 tillgänglig. Om klientprogrammet använder flera databaser och försöker läsa eller skriva till en annan databas än noll genereras följande undantag:
Unhandled Exception: StackExchange.Redis.RedisConnectionException: ProtocolFailure on GET --->
StackExchange.Redis.RedisCommandException: Multiple databases are not supported on this server; cannot switch to database: 6
Mer information finns i Redis-klusterspecifikation – implementerad delmängd.
Om du använder StackExchange.Redis måste du använda 1.0.481 eller senare. Du ansluter till cachen med samma slutpunkter, portar och nycklar som du använder när du ansluter till ett cacheminne där klustring är inaktiverat. Den enda skillnaden är att alla läsningar och skrivningar måste göras till databas 0.
Andra klienter kan ha olika krav. Se Har alla Redis-klienter stöd för klustring?
Om programmet använder flera nyckelåtgärder batchade i ett enda kommando måste alla nycklar finnas i samma shard. Information om hur du hittar nycklar i samma fragment finns i Hur distribueras nycklar i ett kluster?
Om du använder Redis ASP.NET sessionstillståndsprovider måste du använda 2.0.1 eller senare. Se Kan jag använda klustring med Redis ASP.NET sessionstillstånd och cachelagring av utdata?
Viktigt!
När du använder nivåerna Enterprise eller Enterprise FLash får du välja OSS-klusterläge eller Företagsklusterläge. OSS-klusterläget är detsamma som klustring på Premium-nivån och följer specifikationen för öppen källkod klustring. Företagsklusterläget kan vara mindre högpresterande, men använder Redis Enterprise-kluster som inte kräver några klientändringar. Mer information finns i Klustring på företag.
Hur distribueras nycklar i ett kluster?
Enligt Redis-dokumentationen om nyckeldistributionsmodellen: Nyckelutrymmet är uppdelat i 16 384 platser. Varje nyckel hashas och tilldelas till någon av dessa platser, som distribueras över noderna i klustret. Du kan konfigurera vilken del av nyckeln som hashas för att säkerställa att flera nycklar finns i samma fragment med hjälp av hash-taggar.
- Nycklar med en hash-tagg – om någon del av nyckeln omges
{
av och}
, hashas endast den delen av nyckeln för att fastställa hash-platsen för en nyckel. Följande tre nycklar finns till exempel i samma shard:{key}1
, , och{key}3
eftersom endast delenkey
av namnet{key}2
hashas. En fullständig lista över specifikationer för hashtaggar för nycklar finns i Nycklars hashtaggar. - Nycklar utan hash-tagg – hela nyckelnamnet används för hashning, vilket resulterar i en statistiskt jämn fördelning över cachens shards.
För bästa prestanda och dataflöde rekommenderar vi att du distribuerar nycklarna jämnt. Om du använder nycklar med en hash-tagg är det programmets ansvar att se till att nycklarna distribueras jämnt.
Mer information finns i Nyckeldistributionsmodell, Redis-klusterdatasharding och Hash-taggar för nycklar.
Exempelkod om att arbeta med klustring och hitta nycklar i samma shard med StackExchange.Redis-klienten finns i clustering.cs delen av Hello World-exemplet .
Vilken är den största cachestorleken jag kan skapa?
Den största cachestorleken du kan ha är 4,5 TB. Det här resultatet är en klustrad F1500-cache med kapacitet 9. Mer information finns i Prissättning för Azure Cache for Redis.
Stöder alla Redis-klienter klustring?
Många klientbibliotek stöder Redis-klustring, men inte alla. Kontrollera dokumentationen för det bibliotek som du använder för att kontrollera att du använder ett bibliotek och en version som stöder klustring. StackExchange.Redis är ett bibliotek som stöder klustring i nyare versioner. Mer information om andra klienter finns i avsnittet Leka med klustret i redis-klustersjälvstudien.
Redis-klustringsprotokollet kräver att varje klient ansluter till varje shard direkt i klustringsläge och definierar även nya felsvar som MOVED
na CROSSSLOTS
. När du försöker använda ett klientbibliotek som inte stöder klustring, med en cache i klusterläge, kan resultatet bli många undantag för MOVED-omdirigering, eller bara bryta programmet, om du gör multinyckelbegäranden mellan platser.
Kommentar
Om du använder StackExchange.Redis som klient kontrollerar du att du använder den senaste versionen av StackExchange.Redis 1.0.481 eller senare för att klustring ska fungera korrekt. Mer information om eventuella problem med flyttfel finns i flytta undantag.
Hur gör jag för att ansluta till min cache när klustring är aktiverat?
Du kan ansluta till cachen med samma slutpunkter, portar och nycklar som du använder när du ansluter till ett cacheminne som inte har klustring aktiverat. Redis hanterar klustring på serverdelen så att du inte behöver hantera den från klienten.
Kan jag ansluta direkt till de enskilda fragmenten i min cache?
Klustringsprotokollet kräver att klienten gör rätt shardanslutningar, så klienten bör skapa delningsanslutningar åt dig. Med det sagt består varje shard av ett primärt/replikcachepar, som gemensamt kallas för en cacheinstans. Du kan ansluta till dessa cacheinstanser med redis-CLI-verktyget i den instabila grenen av Redis-lagringsplatsen på GitHub. Den här versionen implementerar grundläggande stöd när den startas med växeln -c
. Mer information finns i Spela upp med klustret i https://redis.io redis-klustersjälvstudien.
Du måste använda växeln -p
för att ange rätt port att ansluta till. Använd kommandot KLUSTERNODER för att fastställa exakt vilka portar som används för de primära noderna och repliknoderna. Följande portintervall används:
- För cacheminnen på icke-TLS Premium-nivå är portar tillgängliga i
130XX
intervallet - För TLS-aktiverade Premium-nivåcacheminnen är portar tillgängliga i
150XX
intervallet - För Enterprise- och Enterprise Flash-cacheminnen med OSS-klustring sker den första anslutningen via port 10000. Anslutning till enskilda noder kan göras med hjälp av portar i 85XX-intervallet. 85xx-portarna ändras med tiden och bör inte hårdkodas i ditt program.
Kan jag konfigurera klustring för en tidigare skapad cache?
Ja. Kontrollera först att cachen finns på Premium-nivån genom att skala upp den. Därefter kan du se konfigurationsalternativen för klustret, inklusive ett alternativ för att aktivera kluster. Ändra klusterstorleken när cacheminnet har skapats eller när du har aktiverat klustring för första gången.
Viktigt!
Du kan inte ångra aktivering av klustring. Och en cache med klustring aktiverat och endast en shard fungerar annorlunda än en cache av samma storlek utan klustring.
Alla Enterprise- och Enterprise Flash-nivåcacheminnen är alltid klustrade.
Kan jag konfigurera klustring för en grundläggande cache eller en standardcache?
Klustring är endast tillgängligt för Premium-, Enterprise- och Enterprise Flash-cacheminnen.
Kan jag använda klustring med Redis ASP.NET sessionstillstånd och cachelagring av utdata?
- Redis-utdatacacheprovider – inga ändringar krävs.
- Redis Sessionstillståndsprovider – om du vill använda klustring måste du använda RedisSessionStateProvider 2.0.1 eller senare eller ett undantag genereras, vilket är en icke-bakåtkompatibel ändring. Mer information finns i v2.0.0 Information om icke-bakåtkompatibla ändringar.
Jag får MOVE-undantag när jag använder StackExchange.Redis och klustring, vad ska jag göra?
Om du använder StackExchange.Redis och får MOVE
undantag när du använder klustring kontrollerar du att du använder StackExchange.Redis 1.1.603 eller senare. Anvisningar om hur du konfigurerar .NET-program att använda StackExchange.Redis finns i Konfigurera cacheklienter.
Vad är skillnaden mellan OSS-klustring och Enterprise-klustring på Enterprise-nivåcacheminnen?
OSS-klusterläget är detsamma som klustring på Premium-nivån och följer specifikationen för öppen källkod klustring. Företagsklusterläget kan vara mindre högpresterande, men använder Redis Enterprise-klustring, vilket inte kräver några klientändringar för användning. Mer information finns i Klustring på företag.
Hur många shards använder cacheminnen på Enterprise-nivå?
Till skillnad från cacheminnen på Basic-, Standard- och Premium-nivå kan Enterprise- och Enterprise Flash-cacheminnen dra nytta av flera shards på en enda nod. Mer information finns i Sharding och CPU-användning.