Delen via

Een instantie van Azure Cache voor Redis schalen

  • Artikel

Azure Cache voor Redis heeft verschillende laagaanbiedingen die flexibiliteit bieden bij de keuze van de cachegrootte en -functies. Door te schalen kunt u de grootte, laag en het aantal knooppunten wijzigen nadat u een cache-exemplaar hebt gemaakt om aan uw toepassingsbehoeften te voldoen. In dit artikel leest u hoe u uw cache kunt schalen met behulp van Azure Portal, plus hulpprogramma's zoals Azure PowerShell en Azure CLI.

Typen schalen

Er zijn in wezen twee manieren om een Azure Cache voor Redis-exemplaar te schalen:

  • Als u omhoog schaalt, wordt de grootte van de virtuele machine (VM) waarop de Redis-server wordt uitgevoerd, meer geheugen, virtuele CPU's (vCPU's) en netwerkbandbreedte toegevoegd. Omhoog schalen wordt ook wel verticaal schalen genoemd. Het tegenovergestelde van omhoog schalen is Omlaag schalen.

  • Als u uitschaalt , verdeelt u het cache-exemplaar in meer knooppunten van dezelfde grootte, waardoor het geheugen, de vCPU's en de netwerkbandbreedte worden verhoogd door middel van parallellisatie. Uitschalen wordt ook wel horizontaal schalen of sharding genoemd. Het tegenovergestelde van uitschalen is Inschalen. In de Redis-community wordt uitschalen vaak clustering genoemd.

Bereik van beschikbaarheid

Laag Basic en Standard Premium Enterprise en Enterprise Flash
Omhoog schalen Ja Ja Ja
Omlaag schalen Ja Ja Nr.
Uitschalen Nr. Ja Ja
Inschalen Nr. Ja Nr.

Wanneer schalen

U kunt de bewakingsfuncties van Azure Cache voor Redis gebruiken om de status en prestaties van uw cache te bewaken. Gebruik deze informatie om te bepalen wanneer de cache moet worden geschaald.

U kunt de volgende metrische gegevens controleren om te bepalen of u moet schalen.

  • Redis-server laden
    • Hoge belasting van Redis-servers betekent dat de server niet in staat is om de aanvragen van alle clients te volgen. Omdat een Redis-server één threaded proces is, is het meestal handiger om uit te schalen in plaats van omhoog te schalen. Uitschalen door clustering in te schakelen, helpt overheadfuncties over meerdere Redis-processen te verdelen. Door uit te schalen kunt u ook TLS-versleuteling/ontsleuteling en verbinding/verbinding verbreken, waardoor cache-exemplaren sneller worden gebruikt met BEHULP van TLS.
    • Omhoog schalen kan nog steeds handig zijn bij het verminderen van de serverbelasting, omdat achtergrondtaken kunnen profiteren van de meer vCPU's en de thread vrijmaken voor het hoofdproces van de Redis-server.
    • De lagen Enterprise en Enterprise Flash gebruiken Redis Enterprise in plaats van open source Redis. Een van de voordelen van deze lagen is dat het Redis-serverproces kan profiteren van meerdere vCPU's. Met meerdere vCPU's kan zowel omhoog schalen als uitschalen in deze lagen handig zijn bij het verminderen van de serverbelasting. Zie Best Practices voor de Enterprise- en Enterprise Flash-lagen van Azure Cache voor Redis voor meer informatie.
  • Memory Usage (Geheugengebruik)
    • Hoog geheugengebruik geeft aan dat uw gegevensgrootte te groot is voor de huidige cachegrootte. Overweeg om te schalen naar een cachegrootte met een groter geheugen. Omhoog schalen of uitschalen is hier effectief.
  • Clientverbindingen
    • Elke cachegrootte heeft een limiet voor het aantal clientverbindingen dat kan worden ondersteund. Als uw clientverbindingen dicht bij de limiet voor de cachegrootte liggen, kunt u overwegen om omhoog te schalen naar een grotere laag. Door uit te schalen wordt het aantal ondersteunde clientverbindingen niet verhoogd.
    • Zie Azure Cache voor Redis Prijzen voor meer informatie over verbindingslimieten per cachegrootte.
  • Netwerkbandbreedte
    • Als de Redis-server de beschikbare bandbreedte overschrijdt, kunnen er een time-out optreedt voor clients omdat de server geen gegevens naar de client kan pushen. Als u wilt zien hoeveel bandbreedte aan de serverzijde wordt gebruikt, controleert u de metrische gegevens 'Cache lezen' en 'Cache schrijven'. Als uw Redis-server de beschikbare netwerkbandbreedte overschrijdt, kunt u overwegen om uit te schalen of omhoog te schalen naar een grotere cache met een hogere netwerkbandbreedte.
    • Voor Enterprise-laagcaches die gebruikmaken van het enterprise-clusterbeleid, vergroot uitschalen de netwerkbandbreedte niet.
    • Zie Azure Cache voor Redis veelgestelde vragen over planningen voor meer informatie over de beschikbare netwerkbandbreedte per cachegrootte.
  • Interne Defender-scans
    • In C0 - en C1 Standard-caches, terwijl interne Defender-scans worden uitgevoerd op de VM's, ziet u mogelijk korte pieken in serverbelasting die niet worden veroorzaakt door een toename van cacheaanvragen. U ziet een hogere latentie voor aanvragen terwijl interne Defender-scans een paar keer per dag worden uitgevoerd op deze lagen. Caches op de C0 - en C1-lagen hebben slechts één kern voor multitask, waarbij het werk van het verwerken van interne Defender-scans en Redis-aanvragen wordt verdeeld. U kunt het effect verminderen door te schalen naar een hogere laag met meerdere CPU-kernen, zoals C2.
    • De grotere cachegrootte op de hogere lagen helpt eventuele latentieproblemen op te lossen. Op C2-niveau hebt u ook ondersteuning voor zo veel als 2000 clientverbindingen.

Zie De juiste laag en Azure Cache voor Redis veelgestelde vragen over het plannen van de cacheprijscategorie kiezen voor meer informatie over het bepalen van de te gebruiken cacheprijscategorie.

Notitie

Zie de aanbevolen procedures voor het schalen voor meer informatie over het optimaliseren van het schaalproces

Vereisten/beperkingen voor schalen Azure Cache voor Redis

U kunt omhoog/omlaag schalen naar een andere prijscategorie met de volgende beperkingen:

  • U kunt niet schalen van een hogere prijscategorie naar een lagere prijscategorie.
    • U kunt niet schalen vanuit een Enterprise- of Enterprise Flash-cache naar een andere laag.
    • U kunt niet schalen van een Premium-cache naar een Standard - of Basic-cache .
    • U kunt niet schalen vanuit een Standard-cache naar een Basic-cache .
  • U kunt schalen van een Basic-cache naar een Standard-cache , maar u kunt de grootte niet tegelijkertijd wijzigen. Als u een andere grootte nodig hebt, kunt u later een schaalbewerking uitvoeren op de gewenste grootte.
  • U kunt niet rechtstreeks schalen van een Basic-cache naar een Premium-cache . Schaal eerst van Basic naar Standard in één schaalbewerking en vervolgens van Standard naar Premium in de volgende schaalbewerking.
  • U kunt niet schalen van een grotere grootte naar de C0-grootte (250 MB). U kunt echter inschalen naar elke andere grootte binnen dezelfde prijscategorie. U kunt bijvoorbeeld inschalen van C5 Standard naar C1 Standard.
  • U kunt niet schalen vanuit een Premium-, Standard- of Basic-cache tot een Enterprise- of Enterprise Flash-cache.
  • U kunt niet schalen tussen Enterprise en Enterprise Flash.

U kunt uitschalen/inschalen met de volgende beperkingen:

  • Uitschalen wordt alleen ondersteund in de Premium-, Enterprise- en Enterprise Flash-lagen.
  • Inschalen wordt alleen ondersteund in de Premium-laag.
  • In de Premium-laag moet clustering eerst worden ingeschakeld voordat u in- of uitschaalt.
  • Op de Premium-laag is ondersteuning voor uitschalen tot 10 shards algemeen beschikbaar. Ondersteuning voor maximaal 30 shards is in preview. (Voor caches met twee replica's is de shardlimiet 20. Bij drie replica's is de shardlimiet 15.)
  • Alleen de Enterprise- en Enterprise Flash-lagen kunnen tegelijkertijd omhoog worden geschaald en uitgeschaald.

Schalen - Basic-, Standard- en Premium-lagen

Omhoog en omlaag schalen met behulp van Azure Portal

  1. Als u de cache wilt schalen, bladert u naar de cache in Azure Portal en selecteert u Schalen in het menu Resource.

    Schermopname van Schalen in het resourcemenu.

  2. Kies een prijscategorie in het werkvenster en kies Vervolgens Selecteren.

    Schermopname van de Azure Cache voor Redis lagen.

  3. Terwijl de cache wordt geschaald naar de nieuwe laag, wordt er een melding over het schalen van Redis Cache weergegeven.

    Schermopname van de melding van schalen.

  4. Wanneer het schalen is voltooid, verandert de status van Schalen naar Actief.

Notitie

Wanneer u een cache omhoog of omlaag schaalt met behulp van de portal, worden beide maxmemory-reserved instellingen maxfragmentationmemory-reserved automatisch geschaald in verhouding tot de cachegrootte. Als maxmemory-reserved bijvoorbeeld is ingesteld op 3 GB op een cache van 6 GB en u schaalt naar 12 GB cache, worden de instellingen automatisch bijgewerkt naar 6 GB tijdens het schalen. Wanneer u omlaag schaalt, gebeurt het omgekeerde.

Omhoog en omlaag schalen met PowerShell

U kunt uw Azure Cache voor Redis exemplaren schalen met PowerShell met behulp van de set-AzRedisCache-cmdlet wanneer de Sizeof Sku eigenschappen worden gewijzigd. In het volgende voorbeeld ziet u hoe u een cache met de naam myCache kunt schalen naar een cache van 6 GB in dezelfde laag.

   Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -Size 6GB

Zie Een Azure Cache voor Redis schalen met Behulp van PowerShell voor meer informatie over schalen met PowerShell.

Omhoog en omlaag schalen met behulp van Azure CLI

Als u uw Azure Cache voor Redis-exemplaren wilt schalen met behulp van Azure CLI, roept u de opdracht az redis update aan. Gebruik de sku.capcity eigenschap om te schalen binnen een laag, bijvoorbeeld van een Standard C0 naar Standard C1-cache:

az redis update --cluster-name myCache --resource-group myGroup --set "sku.capacity"="2"

Gebruik de eigenschappen 'sku.name' en 'sku.family' om omhoog te schalen naar een andere laag, bijvoorbeeld van een Standard C1-cache naar een Premium P1-cache:

az redis update --cluster-name myCache --resource-group myGroup --set "sku.name"="Premium" "sku.capacity"="1" "sku.family"="P"

Zie Instellingen van een bestaande Azure Cache voor Redis wijzigen voor meer informatie over schalen met Azure CLI.

Notitie

Wanneer u een cache programmatisch omhoog of omlaag schaalt (bijvoorbeeld met behulp van PowerShell of Azure CLI), worden een maxmemory-reserved of maxfragmentationmemory-reserved meer caches genegeerd als onderdeel van de updateaanvraag. Alleen uw schaalwijziging wordt gehonoreerd. U kunt deze geheugeninstellingen bijwerken nadat de schaalbewerking is voltooid.

Omhoog en uitschalen - Enterprise- en Enterprise Flash-lagen

De Enterprise- en Enterprise Flash-lagen kunnen in één bewerking omhoog schalen en uitschalen. Voor andere lagen zijn afzonderlijke bewerkingen vereist voor elke actie.

Let op

De Enterprise- en Enterprise Flash-lagen bieden nog geen ondersteuning voor omlaag schalen of inschalen van bewerkingen.

Schalen met behulp van Azure Portal

  1. Als u de cache wilt schalen, bladert u naar de cache in Azure Portal en selecteert u Schalen in het menu Resource.

    Schermopname van Schalen geselecteerd in het menu Resource voor een Enterprise-cache.

  2. Als u omhoog wilt schalen, kiest u een ander cachetype en kiest u Opslaan.

    Belangrijk

    U kunt op dit moment alleen omhoog schalen. U kunt niet omlaag schalen.

    Schermopname van de Enterprise-lagen in het werkvenster.

  3. Als u wilt uitschalen, verhoogt u de schuifregelaar Capaciteit . Capaciteit neemt toe in stappen van twee. Dit getal geeft aan hoeveel onderliggende Redis Enterprise-knooppunten worden toegevoegd. Dit getal is altijd een veelvoud van twee om knooppunten weer te geven die worden toegevoegd voor zowel primaire als replica-shards.

    Belangrijk

    U kunt op dit moment alleen uitschalen en de capaciteit vergroten. U kunt niet inschalen.

    Schermopname van Capaciteit in het werkvenster een rood kader eromheen.

  4. Terwijl de cache wordt geschaald naar de nieuwe laag, wordt er een melding over het schalen van Redis Cache weergegeven.

    Schermopname van de melding van het schalen van een Enterprise-cache.

  5. Wanneer het schalen is voltooid, verandert de status van Schalen naar Actief.

Schalen met Behulp van PowerShell

U kunt uw Azure Cache voor Redis-exemplaren schalen met PowerShell met behulp van de cmdlet Update-AzRedisEnterpriseCache. U kunt de Sku eigenschap wijzigen om het exemplaar omhoog te schalen. U kunt de Capacity eigenschap wijzigen om het exemplaar uit te schalen. In het volgende voorbeeld ziet u hoe u een cache met de naam myCache schaalt naar een Enterprise E20-exemplaar (25 GB) met een capaciteit van 4.

   Update-AzRedisEnterpriseCache -ResourceGroupName myGroup -Name myCache -Sku Enterprise_E20 -Capacity 4

Schalen met behulp van Azure CLI

Als u uw Azure Cache voor Redis-exemplaren wilt schalen met behulp van Azure CLI, roept u de opdracht az redisenterprise update aan. U kunt de sku eigenschap wijzigen om het exemplaar omhoog te schalen. U kunt de capacity eigenschap wijzigen om het exemplaar uit te schalen. In het volgende voorbeeld ziet u hoe u een cache met de naam myCache schaalt naar een Enterprise E20-exemplaar (25 GB) met een capaciteit van 4.

az redisenterprise update --cluster-name "myCache" --resource-group "myGroup" --sku "Enterprise_E20" --capacity 4

Veelgestelde vragen over schalen

De volgende lijst bevat antwoorden op veelgestelde vragen over Azure Cache voor Redis schalen.

Kan ik schalen naar, van of naar een Premium-cache?

  • U kunt niet schalen vanuit een Premium-cache naar een Basic - of Standard-prijscategorie .
  • U kunt schalen van de ene Prijscategorie voor Premium-cache naar een andere.
  • U kunt niet rechtstreeks schalen van een Basic-cache naar een Premium-cache . Schaal eerst van Basic naar Standard in één schaalbewerking en vervolgens van Standard naar Premium in een latere schaalbewerking.
  • U kunt niet schalen van een Premium-cache naar een Enterprise - of Enterprise Flash-cache .
  • Als u clustering hebt ingeschakeld tijdens het maken van uw Premium-cache , kunt u de clustergrootte wijzigen. Als uw cache is gemaakt zonder clustering ingeschakeld, kunt u clustering op een later tijdstip configureren.

Na het schalen moet ik mijn cachenaam of toegangssleutels wijzigen?

Nee, uw cachenaam en -sleutels zijn ongewijzigd tijdens een schaalbewerking.

Hoe werkt schalen?

  • Wanneer u een Basic-cache naar een andere grootte schaalt, wordt de cache afgesloten en wordt een nieuwe cache ingericht met de nieuwe grootte. Gedurende deze tijd is de cache niet beschikbaar en gaan alle gegevens in de cache verloren.
  • Wanneer u een Basic-cache schaalt naar een Standard-cache , wordt een replicacache ingericht en worden de gegevens gekopieerd van de primaire cache naar de replicacache. De cache blijft beschikbaar tijdens het schaalproces.
  • Wanneer u een Standard-, Premium-, Enterprise- of Enterprise Flash-cache naar een andere grootte schaalt, wordt een van de replica's afgesloten en opnieuw ingericht voor de nieuwe grootte en de gegevens die worden overgedragen. Vervolgens voert de andere replica een failover uit voordat deze opnieuw wordt ingericht, vergelijkbaar met het proces dat optreedt tijdens een storing van een van de cacheknooppunten.
  • Wanneer u een geclusterde cache uitschaalt, worden nieuwe shards ingericht en toegevoegd aan het Redis-servercluster. Gegevens worden vervolgens opnieuw gehard voor alle shards.
  • Wanneer u in een geclusterde cache schaalt, worden de gegevens eerst opnieuw gehard en wordt de clustergrootte verkleind tot vereiste shards.
  • In sommige gevallen, zoals het schalen of migreren van uw cache naar een ander cluster, kan het onderliggende IP-adres van de cache worden gewijzigd. De DNS-record voor de cache verandert en is transparant voor de meeste toepassingen. Als u echter een IP-adres gebruikt om de verbinding met uw cache te configureren of om NSG's of firewalls te configureren die verkeer naar de cache toestaan, kan het zijn dat uw toepassing enige tijd problemen ondervindt bij het maken van verbinding nadat de DNS-recordupdates zijn bijgewerkt.

Verlies ik gegevens uit mijn cache tijdens het schalen?

  • Wanneer u een Basic-cache naar een nieuwe grootte schaalt, gaan alle gegevens verloren en is de cache niet beschikbaar tijdens de schaalbewerking.
  • Wanneer u een Basic-cache schaalt naar een Standard-cache , blijven de gegevens in de cache doorgaans behouden.
  • Wanneer u een Standard-, Premium-, Enterprise- of Enterprise Flash-cache schaalt naar een grotere grootte, blijven alle gegevens doorgaans behouden. Wanneer u een Standard- of Premium-cache schaalt naar een kleiner formaat, kunnen gegevens verloren gaan als de gegevens groter zijn dan de nieuwe kleinere cache wanneer de cache omlaag wordt geschaald. Als gegevens verloren gaan bij omlaag schalen, worden sleutels verwijderd met behulp van het verwijderingsbeleid allkeys-lru .

Kan ik na het schalen alle functies van de Premium-laag gebruiken?

Nee, sommige functies kunnen alleen worden ingesteld wanneer u een cache maakt in de Premium-laag en niet beschikbaar is na het schalen.

Deze functies kunnen niet worden toegevoegd nadat u de Premium-cache hebt gemaakt:

  • Virtuele netwerkinjectie
  • Zoneredundantie toevoegen
  • Meerdere replica's per primaire replica gebruiken

Als u een van deze functies wilt gebruiken, moet u een nieuw cache-exemplaar maken in de Premium-laag.

Wordt de instelling van mijn aangepaste databases beïnvloed tijdens het schalen?

Als u een aangepaste waarde hebt geconfigureerd voor de instelling tijdens het maken van de databases cache, moet u er rekening mee houden dat sommige prijscategorieën verschillende databaselimieten hebben. Hier volgen enkele overwegingen bij het schalen in dit scenario:

  • Wanneer u schaalt naar een prijscategorie met een lagere databases limiet dan de huidige categorie:
    • Als u het standaardaantal databases, dat 16 is voor alle prijscategorieën, gebruikt, gaan er geen gegevens verloren.
    • Als u een aangepast aantal databases gebruikt dat binnen de limieten valt voor de laag waarvoor u schaalt, wordt deze databases instelling bewaard en gaan er geen gegevens verloren.
    • Als u een aangepast aantal databases gebruikt dat de limieten van de nieuwe laag overschrijdt, wordt de databases instelling verlaagd tot de limieten van de nieuwe laag en gaan alle gegevens in de verwijderde databases verloren.
  • Wanneer u schaalt naar een prijscategorie met dezelfde of hogere databases limiet dan de huidige laag, wordt uw databases instelling bewaard en gaan er geen gegevens verloren.

Hoewel Standard-, Premium-, Enterprise- en Enterprise Flash-caches een SLA hebben voor beschikbaarheid, is er geen SLA voor gegevensverlies.

Is mijn cache beschikbaar tijdens het schalen?

  • Standard-, Premium-, Enterprise- en Enterprise Flash-caches blijven beschikbaar tijdens de schaalbewerking. Verbindingslips kunnen echter optreden tijdens het schalen van deze caches, en ook tijdens het schalen van Basic naar Standard-caches . Deze verbindingslips zijn naar verwachting klein en redis-clients kunnen hun verbinding over het algemeen onmiddellijk opnieuw tot stand brengen.
  • Voor Enterprise- en Enterprise Flash-caches die actieve geo-replicatie gebruiken, kan het schalen van slechts een subset van gekoppelde caches in sommige gevallen problemen veroorzaken. We raden u aan om waar mogelijk alle caches in de geo-replicatiegroep samen te schalen.
  • Basiscaches zijn offline tijdens schaalbewerkingen naar een andere grootte. Basiscaches blijven beschikbaar bij het schalen van Basic naar Standard , maar kunnen een kleine verbindingslip ervaren. Als er een verbindingslip optreedt, kunnen Redis-clients hun verbinding over het algemeen onmiddellijk opnieuw tot stand brengen.

Zijn er schaalbeperkingen met geo-replicatie?

Als passieve geo-replicatie is geconfigureerd, merkt u mogelijk dat u een cache niet kunt schalen of de shards in een cluster kunt wijzigen. Een geo-replicatiekoppeling tussen twee caches voorkomt dat u de schaalbewerking kunt aanpassen of het aantal shards in een cluster kunt wijzigen. U moet de cache ontkoppelen om deze opdrachten uit te voeren. Zie Geo-replicatie configureren voor meer informatie.

Als actieve geo-replicatie is geconfigureerd, kunt u een cache niet schalen. Alle caches in een geo-replicatiegroep moeten dezelfde grootte en capaciteit hebben.

Bewerkingen die niet worden ondersteund

  • U kunt niet schalen van een hogere prijscategorie naar een lagere prijscategorie.
    • U kunt niet schalen van een Premium-cache naar een Standard - of Basic-cache .
    • U kunt niet schalen vanuit een Standard-cache naar een Basic-cache .
  • U kunt schalen van een Basic-cache naar een Standard-cache , maar u kunt de grootte niet tegelijkertijd wijzigen. Als u een andere grootte nodig hebt, kunt u een schaalbewerking uitvoeren naar de gewenste grootte op een later tijdstip.
  • U kunt niet rechtstreeks schalen van een Basic-cache naar een Premium-cache . Schaal eerst van Basic naar Standard in één schaalbewerking en schaal vervolgens in een latere bewerking van Standard naar Premium .
  • U kunt niet schalen van een Premium-cache naar een Enterprise - of Enterprise Flash-cache .
  • U kunt niet schalen van een grotere grootte naar de grootte C0 (250 MB).

Als een schaalbewerking mislukt, probeert de service de bewerking te herstellen en wordt de cache teruggezet naar de oorspronkelijke grootte.

Hoe lang duurt het schalen?

Schaaltijd is afhankelijk van een paar factoren. Hier volgen enkele factoren die van invloed kunnen zijn op hoe lang schalen duurt.

  • Hoeveelheid gegevens: het duurt langer om grotere hoeveelheden gegevens te repliceren
  • Hoge schrijfaanvragen: een hoger aantal schrijfbewerkingen betekent dat er meer gegevens worden gerepliceerd tussen knooppunten of shards
  • Hoge serverbelasting: hogere serverbelasting betekent dat de Redis-server bezet is en dat er beperkte CPU-cycli beschikbaar zijn om de herdistributie van gegevens te voltooien

Het schalen van een cache is niet-triviale actie en kan lang duren.

Op basis van praktijkvoorbeelden kan de tijd voor het schalen van de cache met één tot twee shards 1 tot 2 uur duren wanneer de cache niet zwaar wordt belast. Als u meer shards hebt, neemt de tijd die u wilt schalen niet op een lineaire manier toe.

Hoe kan ik zien wanneer schalen is voltooid?

In Azure Portal ziet u de schaalbewerking die wordt uitgevoerd. Wanneer het schalen is voltooid, wordt de status van de cache gewijzigd in Actief.

Moet ik wijzigingen aanbrengen in mijn clienttoepassing om clustering te kunnen gebruiken?

Belangrijk

Wanneer u de Enterprise- of Enterprise FLash-lagen gebruikt, krijgt u de keuze uit oss-clustermodus of bedrijfsclustermodus. OSS-clustermodus is hetzelfde als clustering op de Premium-laag en volgt de opensource-clusteringspecificatie. De bedrijfsclustermodus kan minder goed werken, maar gebruikt Redis Enterprise-clustering waarvoor geen clientwijzigingen nodig zijn. Zie Clustering in Enterprise voor meer informatie.

Hoe worden sleutels gedistribueerd in een cluster?

Volgens de Redis-documentatie over het distributiemodel sleutels: de sleutelruimte wordt gesplitst in 16.384 sleuven. Elke sleutel wordt gehasht en toegewezen aan een van deze sites, die worden verdeeld over de knooppunten van het cluster. U kunt configureren welk deel van de sleutel is gehasht om ervoor te zorgen dat meerdere sleutels zich in dezelfde shard bevinden met behulp van hashtags.

  • Sleutels met een hash-tag: als een deel van de sleutel is ingesloten { en }alleen dat deel van de sleutel wordt gehasht voor het bepalen van de hash-site van een sleutel. De volgende drie sleutels bevinden zich bijvoorbeeld in dezelfde shard: {key}1, {key}2en {key}3 omdat alleen het key deel van de naam is gehasht. Zie Hash-tags voor sleutels voor een volledige lijst met hashtagspecificaties voor sleutels.
  • Sleutels zonder hash-tag: de volledige sleutelnaam wordt gebruikt voor hashing, wat resulteert in een statistische gelijkmatige verdeling over de shards van de cache.

Voor de beste prestaties en doorvoer raden we u aan de sleutels gelijkmatig te distribueren. Als u sleutels met een hash-tag gebruikt, is het de verantwoordelijkheid van de toepassing om ervoor te zorgen dat de sleutels gelijkmatig worden gedistribueerd.

Zie voor meer informatie het distributiemodel sleutels, redis cluster gegevens sharding en sleutels hash-tags.

Zie het clustering.cs gedeelte van het Hallo wereld voorbeeld voor voorbeeldcode over het werken met clustering en het zoeken van sleutels in dezelfde shard met de StackExchange.Redis-client.

Wat is de grootste cachegrootte die ik kan maken?

De grootste cachegrootte die u kunt hebben, is 4,5 TB. Dit resultaat is een geclusterde F1500-cache met capaciteit 9. Zie Prijzen van Azure Cache voor Redis voor meer informatie.

Ondersteunen alle Redis-clients clustering?

Veel clientsbibliotheken ondersteunen Redis-clustering, maar niet alle. Raadpleeg de documentatie voor de bibliotheek die u gebruikt om te controleren of u een bibliotheek en versie gebruikt die clustering ondersteunen. StackExchange.Redis is één bibliotheek die clustering ondersteunt, in de nieuwere versies. Zie de sectie Afspelen met het cluster van de zelfstudie redis-cluster voor meer informatie over andere clients.

Voor het Redis-clusteringprotocol moet elke client rechtstreeks verbinding maken met elke shard in de clustermodus en worden ook nieuwe foutreacties zoals MOVED na CROSSSLOTSgedefinieerd. Wanneer u probeert een clientbibliotheek te gebruiken die geen ondersteuning biedt voor clustering, met een cache in de clustermodus, kan het resultaat veel omleidingsuitzonderingsuitzondering zijn of uw toepassing verbreken, als u aanvragen met meerdere sleutels voor meerdere sleutels uitvoert.

Notitie

Als u StackExchange.Redis als client gebruikt, controleert u of u de nieuwste versie van StackExchange.Redis 1.0.481 of hoger gebruikt om clustering correct te laten werken. Zie verplaatsingsonderzondering voor meer informatie over eventuele problemen met verplaatsingsonderzondering.

Hoe kan ik verbinding maken met mijn cache wanneer clustering is ingeschakeld?

U kunt verbinding maken met uw cache met behulp van dezelfde eindpunten, poorten en sleutels die u gebruikt wanneer u verbinding maakt met een cache waarvoor clustering niet is ingeschakeld. Redis beheert de clustering op de back-end, zodat u deze niet hoeft te beheren vanaf uw client.

Kan ik rechtstreeks verbinding maken met de afzonderlijke shards van mijn cache?

Voor het clusteringprotocol moet de client de juiste shardverbindingen maken, zodat de client verbindingen voor u moet delen. Met dat gezegd, elke shard bestaat uit een primaire/replica-cachepaar, gezamenlijk bekend als een cache-exemplaar. U kunt verbinding maken met deze cache-exemplaren met behulp van het hulpprogramma Redis-CLI in de instabiele vertakking van de Redis-opslagplaats op GitHub. Met deze versie wordt basisondersteuning geïmplementeerd wanneer deze met de -c switch wordt gestart. Zie Afspelen met het cluster https://redis.io in de zelfstudie redis-cluster voor meer informatie.

U moet de -p switch gebruiken om de juiste poort op te geven waarmee u verbinding wilt maken. Gebruik de opdracht CLUSTERKNOOPPUNTen om de exacte poorten te bepalen die worden gebruikt voor de primaire en replicaknooppunten. De volgende poortbereiken worden gebruikt:

  • Voor caches met niet-TLS Premium-lagen zijn poorten beschikbaar in het 130XX bereik
  • Voor caches met TLS-laag met Premium zijn poorten beschikbaar in het 150XX bereik
  • Voor Enterprise- en Enterprise Flash-caches met OSS-clustering is de eerste verbinding via poort 10000. U kunt verbinding maken met afzonderlijke knooppunten met behulp van poorten in het bereik 85XX. De 85xx-poorten worden na verloop van tijd gewijzigd en mogen niet in uw toepassing worden vastgelegd.

Kan ik clustering configureren voor een eerder gemaakte cache?

Ja. Zorg er eerst voor dat uw cache zich in de Premium-laag bevindt door deze omhoog te schalen. Vervolgens ziet u de clusterconfiguratieopties, inclusief een optie om cluster in te schakelen. Wijzig de clustergrootte nadat de cache is gemaakt of nadat u clustering voor het eerst hebt ingeschakeld.

Belangrijk

U kunt het inschakelen van clustering niet ongedaan maken. En een cache met clustering ingeschakeld en slechts één shard gedraagt zich anders dan een cache met dezelfde grootte zonder clustering.

Alle caches voor Enterprise- en Enterprise Flash-lagen worden altijd geclusterd.

Kan ik clustering configureren voor een basis- of standaardcache?

Clustering is alleen beschikbaar voor Premium-, Enterprise- en Enterprise Flash-caches.

Kan ik clustering gebruiken met de Redis ASP.NET Session State and Output Caching providers?

  • Redis Output Cache-provider : er zijn geen wijzigingen vereist.
  • Redis Session State Provider : als u clustering wilt gebruiken, moet u RedisSessionStateProvider 2.0.1 of hoger gebruiken of een uitzondering wordt gegenereerd. Dit is een wijziging die fouten veroorzaakt. Zie v2.0.0. Details van wijziging die fouten veroorzaken voor meer informatie.

Ik krijg MOVE-uitzonderingen bij het gebruik van StackExchange.Redis en clustering. Wat moet ik doen?

Als u StackExchange.Redis gebruikt en uitzonderingen ontvangt MOVE bij het gebruik van clustering, controleert u of u StackExchange.Redis 1.1.603 of hoger gebruikt. Zie De cacheclients configureren voor instructies over het configureren van uw .NET-toepassingen voor het gebruik van StackExchange.Redis.

Wat is het verschil tussen OSS-clustering en Enterprise Clustering in enterprise-laagcaches?

OSS-clustermodus is hetzelfde als clustering op de Premium-laag en volgt de opensource-clusteringspecificatie. De bedrijfsclustermodus kan minder goed werken, maar gebruikt Redis Enterprise-clustering, waarvoor geen clientwijzigingen nodig zijn. Zie Clustering in Enterprise voor meer informatie.

Hoeveel shards gebruiken Enterprise-laagcaches?

In tegenstelling tot caches in de Basic-, Standard- en Premium-laag, Enterprise- en Enterprise Flash-caches kunnen gebruikmaken van meerdere shards op één knooppunt. Zie Sharding en CPU-gebruik voor meer informatie.

Volgende stappen