Azure Cache voor Redis configureren
Uw ontwikkelingsteam voor sportstatistieken heeft besloten dat caching de prestaties voor onlangs aangevraagde gegevens aanzienlijk kan verbeteren. De volgende stap is het maken en configureren van een instantie van Azure Cache voor Redis.
Een instantie van Azure Cache voor Redis maken en configureren
U kunt een Redis-cache maken met de Azure-portal, de Azure CLI of Azure PowerShell. Er zijn verschillende parameters die u moet bepalen om de cache correct te configureren voor uw doeleinden.
Naam
Uw Redis-cache heeft een wereldwijd unieke naam nodig. De naam moet uniek zijn binnen Azure, omdat deze wordt gebruikt om een openbare URL te genereren om verbinding te maken en te communiceren met de service.
De naam moet tussen 1 en 63 tekens bestaan uit cijfers, letters en het - teken. De cachenaam kan niet beginnen of eindigen met het - teken en opeenvolgende - tekens zijn niet geldig.
Resourcegroep
Azure Cache voor Redis is een beheerde resource en heeft een resourcegroepeigenaar nodig. U kunt een nieuwe resourcegroep maken of een bestaand resourcegroep gebruiken in een abonnement waartoe u toegang hebt.
Locatie
U moet bepalen waar de Redis-cache zich fysiek bevindt door een Azure-regio te selecteren. Plaats uw instantie van de cache en uw toepassing altijd in dezelfde regio. Als er verbinding wordt gemaakt met een cache in een andere regio, kan dit leiden tot een aanzienlijk hogere latentie en kan dit ten koste gaan van de betrouwbaarheid. Als u verbinding maakt met de cache buiten Azure, selecteert u een locatie dicht bij de locatie waar de toepassing de gegevens gebruikt.
Belangrijk
Plaats de Redis-cache zo dicht mogelijk bij de consument van de gegevens.
Prijscategorie
Zoals vermeld in de vorige eenheid, zijn er drie prijscategorieën beschikbaar voor een Azure Cache voor Redis.
- Basic: De Basic-cache is ideaal voor ontwikkeling/testen. Het is beperkt tot één server, 53 GB geheugen en 20.000 verbindingen. Er is geen SLA voor deze servicelaag.
- Standaard: dit is de productiecache, die replicatie ondersteunt en een SLA van 99,99% bevat. Het ondersteunt twee servers (primair/secundair) en heeft dezelfde geheugen-/verbindingslimieten als de Basic-laag.
- Premium: Dit is de Enterprise-laag, die voortbouwt op de Standard-laag en persistentie, clustering en ondersteuning voor scale-outcache omvat. Premium is de best presterende laag, met maximaal 530 GB geheugen en 40.000 gelijktijdige verbindingen.
U kunt de hoeveelheid cachegeheugen die beschikbaar is voor elke laag beheren door een cacheniveau te kiezen van C0-C6 voor Basic/Standard en P0-P4 voor Premium. Bekijk de speciale pagina met prijzen voor meer informatie.
Tip
Microsoft raadt u aan altijd de Standard- of Premium-laag te gebruiken voor productiesystemen. De Basic-laag is een systeem met één knooppunt zonder gegevensreplicatie en geen SLA. Gebruik minimaal een C1-cache. C0-caches zijn echt bedoeld voor eenvoudige ontwikkel-/testscenario's, omdat ze een gedeelde CPU-kern en zeer weinig geheugen hebben.
Met de Premium-laag kunt u gegevens op twee manieren behouden voor herstel na noodgevallen:
RDB-persistentie maakt een periodieke momentopname en kan de cache opnieuw opbouwen met behulp van de momentopname als er een fout optreedt.
AOF-persistentie slaat elke schrijfbewerking op naar een logboek dat ten minste één keer per seconde wordt opgeslagen. AOF maakt grotere bestanden dan RDB, maar heeft minder gegevensverlies.
Er zijn verschillende andere instellingen die alleen beschikbaar zijn voor de Premium-laag .
Ondersteuning voor virtuele netwerken
Als u een Redis-cache met premium lagen maakt, kunt u deze implementeren in een virtueel netwerk in de cloud. Uw cache is alleen beschikbaar voor andere virtuele machines en toepassingen in hetzelfde virtuele netwerk. Implementeren in een virtueel netwerk biedt een hoger beveiligingsniveau wanneer uw service en cache beide worden gehost in Azure of zijn verbonden via een VPN van een virtueel Azure-netwerk.
Ondersteuning van clusters
Met een Redis-cache uit de Premium-categorie kunt u clustering implementeren als u automatisch uw gegevensset wilt verdelen over meerdere knooppunten. Voor het implementeren van clusters moet u een aantal shards tot maximaal 10 opgeven. De gemaakte kosten zijn de kosten van het oorspronkelijke knooppunt vermenigvuldigd met het aantal shards.
Toegang tot het Redis-exemplaar
Redis biedt ondersteuning voor een set bekende opdrachten. Een opdracht wordt meestal uitgevoerd als COMMAND parameter1 parameter2 parameter3.
Hier volgen enkele veelgebruikte opdrachten die u kunt gebruiken:
| Opdracht | Beschrijving |
|---|---|
ping |
Pingt de server. Retourneert 'PONG'. |
set [key] [value] |
Hiermee wordt een sleutel/waarde ingesteld in de cache. Retourneert 'OK' wanneer het is gelukt. |
get [key] |
Hiermee wordt een waarde opgehaald uit de cache. |
exists [key] |
Retourneert '1' als de sleutel in de cache bestaat, '0' als dit niet het probleem is. |
type [key] |
Hiermee wordt het type geretourneerd dat is gekoppeld aan de waarde voor de opgegeven sleutel. |
incr [key] |
Verhoog de opgegeven waarde die is gekoppeld aan de sleutel met één. De waarde moet een geheel getal of een dubbele waarde zijn. Retourneert de nieuwe waarde. |
incrby [key] [amount] |
De opgegeven waarde die aan de sleutel is gekoppeld, verhogen met de opgegeven waarde. De waarde moet een geheel getal of een dubbele waarde zijn. Retourneert de nieuwe waarde. |
del [key] |
Hiermee word de waarde verwijderd die aan de sleutel is gekoppeld. |
flushdb |
Verwijder alle sleutels en waarden in de database. |
Redis heeft een opdrachtregelprogramma (redis cli) dat u kunt gebruiken om direct met deze opdrachten te experimenteren. Hieronder vindt u enkele voorbeelden.
> set somekey somevalue
OK
> get somekey
"somevalue"
> exists somekey
(string) 1
> del somekey
(string) 1
> exists somekey
(string) 0
Hier volgt een voorbeeld van het werken met de INCR-opdrachten. Deze opdrachten zijn handig omdat ze atomische stappen bieden voor meerdere toepassingen die gebruikmaken van de cache.
> set counter 100
OK
> incr counter
(integer) 101
> incrby counter 50
(integer) 151
> type counter
(integer)
Een verlooptijd toevoegen aan waarden
Opslaan in cache is belangrijk omdat we zodoende veelgebruikte waarden in het geheugen opslaan. We hebben echter ook een manier nodig om waarden te laten verlopen wanneer ze verouderd zijn. Redis verwerkt verlooptijd door een time to live (TTL) toe te passen op een sleutel.
Wanneer de TTL is verstreken, wordt de sleutel automatisch verwijderd, precies alsof de DEL opdracht is uitgegeven. Hieronder vindt u enkel opmerkingen met betrekking tot TTL-verlooptijden.
- De verlooptijd kunnen op de seconde of milliseconde worden ingesteld.
- De resolutie van de verlooptijd is altijd één milliseconden.
- De tijd verloopt virtueel, zelfs wanneer uw Redis-server gestopt blijft.
- Verloopgegevens worden gerepliceerd en blijven behouden op schijf.
- Redis slaat de datum op waarop een sleutel verloopt.
Hier volgt een voorbeeld van een vervaldatum:
> set counter 100
OK
> expire counter 5
(integer) 1
> get counter
100
... wait ...
> get counter
(nil)
Toegang tot een Redis-cache vanaf een client
Als u verbinding wilt maken met een instantie van Azure Cache voor Redis, hebt u verschillende gegevens nodig. Clients hebben de hostnaam, de poort en een toegangssleutel voor de cache nodig. U kunt deze informatie ophalen in Azure Portal via de pagina Instellingen > Toegangssleutels.
De hostnaam is het openbare internetadres van uw cache, dat is gemaakt met behulp van de naam van de cache; bijvoorbeeld
sportsresults.redis.cache.windows.net.De toegangssleutel fungeert als een wachtwoord voor uw cache. Er zijn twee sleutels gemaakt: een primaire en secundaire sleutel. U kunt een van beide sleutels gebruiken en er zijn twee opgegeven voor het geval u de primaire sleutel moet wijzigen. U kunt al uw clients overschakelen naar de secundaire sleutel en de primaire sleutel opnieuw genereren. Toepassingen die gebruikmaken van de oorspronkelijke primaire sleutel, worden echter geblokkeerd. Microsoft raadt aan om de sleutels periodiek opnieuw te genereren, net zoals u uw persoonlijke wachtwoorden zou doen.
Waarschuwing
Uw toegangssleutels moeten worden beschouwd als vertrouwelijke informatie; behandel ze zoals u een wachtwoord zou gebruiken. Iedereen met een toegangssleutel kan uw cache bewerken.