Redis klientsiden hurtigbufring
Caching på klientsiden muliggjør lagring av ofte tilgang til data i nettleserens slutt eller i applikasjonsserverens minne. Det bruker lagring av klientsiden til en viss grad, men ytelsesgevinsten er høy. Vanligvis, når dataene er påkrevd, sender klienten en forespørsel til baksiden av spørringsdata. Det meste av tiden henter webklienter det samme settet med data om og om igjen fra databasen. Med klientsiden-hurtigbufring aktivert, lagres data hentet via populære spørsmål på klientsiden.
Caching av klientsiden har to hovedfordeler:
- Forbedrer ytelsen med et betydelig beløp.
- Reduserer databasen og nettverksbelastningen.
Samtidig står cache på klientsiden overfor utfordringen med å holde oppdaterte data. Hvis dataene blir endret i databasen, blir den delen av data i klientbufferen utdatert, og klienten bør varsles umiddelbart om å hente det oppdaterte stykket. Redis har implementert sin hurtigbufringsmodell ved å løse disse problemene.
Sett opp hurtigbufring av klientsiden med Redis
I Redis heter Cache sporing. Det er to sporingsmåter støttet av Redis. Standardmodus kalles serverassistert sporing, der serveren sender ugyldighetsvarsler som bare er relatert til nøklene som er i klientbufferen. På den annen side gir kringkastingsmodus frihet for klienter å abonnere på foretrukne viktige prefikser og motta varsler når en nøkkel med det abonnementet er endret.
Serverassistert sporing for Redis-klienter
Som navnet antyder, i serverassistert modus, holder serveren oversikt over nøklene som en spesifikk klient får tilgang til. Hver gang en sporet nøkkel endres i databasen, vil klienten bli varslet umiddelbart. Det viktigste er at ugyldighetsvarsler bare genereres for nøklene som er i en gitt klientbuffer. Den eneste ulempen med denne modusen er at den utnytter serverminnet for å huske de tilgjengelige tastene av hver klient.
Dedikert klient for ugyldige varsler
Vanligvis implementeres den serverassisterte hurtigbufringen. Denne klienten er det sentrale punktet som mottar alle ugyldige meldinger for alle klientene som er koblet til en gitt database.
La oss sette opp en dedikert klient for å motta ugyldige meldinger. Først må vi koble oss til Redis -serveren vår som en autorisert klient og få klientens ID som følger.
klient-ID
Kommandoen ovenfor returnerer IDen til den nåværende klientforbindelsen, som er 3. Denne IDen er nødvendig i de neste trinnene for å identifisere den som den sentrale klienten for å motta ugyldige meldinger. Deretter abonnerer vi på ugyldig varslingskanal som følger. Abonner -kommandoen kan brukes.
Abonner Channel [Channel…]
I dette eksemplet er kanalen __redis __: ugyldig.
abonner __redis __: ugyldig
Nå har vi satt opp klientforbindelsen for å motta ugyldige varsler. La oss sette i gang en annen klientforbindelse og slå på klientsporing. Videre omdirerer vi alle ugyldige meldinger knyttet til den nye klienten til den sentrale klienten som ble opprettet i det tidligere trinnet. Vi kan bruke klientsporingskommandoen for å oppnå dette. Følgende er syntaks for klientsporingskommandoen.
Klientsporing[Redirect client-id] [Prefiks prefiks [prefiks prefiks…]] [bcast] [optin] [optout] [noloop]
På | AV : Bestemme om klientsporing skal være aktivert eller ikke.
Omdirigere: Spesifiser IDen til klienten som mottar ugyldige meldinger.
La oss aktivere klientsporing for en ny autorisert klient og bruke omdirigeringsalternativet til å spesifisere tilkoblingen som mottar ugyldigheten, meldinger som er 3.
Klientsporing på omdirigering 3
Nå er vi klare til å teste vår Redis -klientsporing. Først setter vi et nøkkelverdipar som følger.
Angi brukernavn "user_01"
Deretter får vi tilgang til brukernavnet fra samme klient, som vil cache det informasjonen på klientsiden siden vi har aktivert klientsporing.
Få brukernavn
La oss åpne en ny klient og endre verdien som er lagret i nøkkelen Brukernavn følgende.
Angi brukernavn "user_2"
Umiddelbart blir klienten som har abonnert på ugyldig kanal, varslet om at verdien som er lagret på nøkkelen Brukernavn har blitt endret og det er allerede ugyldig.
Denne modellen er basert på RESP2 -protokollen, som er standard protokoll Redis -klienter bruker.
Resp3 -protokoll for å motta varsler til sporingsklienten
Fra versjon 6.0, introduserer Redis Resp3 -protokollen, som gjør det mulig for en aktiv klient å motta ugyldige meldinger. Dette er en stor fordel der en Redis -klient kan lytte til en gitt kanal mens han utsteder kommandoer.
La oss sjekke Redis -versjonen først. Det må være versjon 6.0 eller den siste som bruker RESP3 -protokollen. Følgende kommando kan utstedes for å sjekke Redis -versjonen.
Redis-CLI-Versjon
Siden det er versjon 7.0, vi er alle gode til å bruke RESP3 -protokollen. Redis -klienter bruker Resp2 som standard. Så vi må bytte til RESP3 -protokollen.
Hei 3
Dette vil endre protokollen til RESP3 med følgende utgang.
La oss aktivere klientsporing som i det tidligere eksemplet ved å bruke klientsporingskommandoen. I dette tilfellet trenger vi ikke å spesifisere omdirigeringsalternativet.
Klientsporing på
Nå blir tastene denne klienten henter sporet av serveren. I tillegg, når verdien av en sporet nøkkel endres, vil en ugyldighetsmelding bli sendt til klientene som hurtiget den aktuelle nøkkelen.
La oss hente nøkkelen Brukernavn.
Få brukernavn
Klienten cacher Brukernavn Nøkkel og tilhørende verdi. Nå starter vi en annen klientforbindelse og endrer verdien som er lagret i nøkkelen Brukernavn.
Hvis du sjekker den forrige klientforbindelsen, er det ingen ugyldighetsmelding mottatt ennå. Hvis du utsteder en annen kommando, vil ugyldighetsvarslingen vises umiddelbart som følger.
2. Kringkastingsmodus for klientsporing
I standardmodus får klienter ugyldige varsler bare for nøklene som de har hentet i tidligere kommandoanrop. Med kringkastingsmodus aktivert, abonnerer klienter på et spesifikt nøkkelprefiks, og klienten får ugyldighetsvarsler for hver nøkkel som blir endret hvis nøkkel starter med det abonnementet prefikset.
La oss bruke en ny klientforbindelse for å motta ugyldige meldinger ved å abonnere på ugyldig kanal som følger.
I dette eksemplet er klientforbindelses -IDen 10, som vil bli brukt med omdirigeringsalternativet for en ny klient. La oss spesifisere BCAST -alternativet i klientsporingskommandoen som følger.
Klientsporing på BCAST Prefix -bruker: Redirect 10
Anta at vi har en nøkkel som heter bruker: ID: 1 i Redis -forekomsten. La oss få det fra denne klienten.
Nå er brukeren: ID: 1 -nøkkel hurtiget på klientsiden.
La oss opprette en ny klientforbindelse og angi en ny nøkkel som følger: Bruker: ID: 3.
For øyeblikket får klienten som aktivert sporing en ugyldig melding, og den vil bli omdirigert til klienten som blir identifisert av ID 10. Dette skjer fordi den nye nøkkelen inneholder prefikset bruker: som er det abonnerte prefikset av sporingsaktivert klient. Som du ser, holder serveren ikke oversikt over noen av nøklene som hver klient henter, men den sender ugyldige meldinger hvis det endrede nøkkelprefikset samsvarer med det abonnementet prefikset av hver klient.
Optin- og optoutalternativer
Optin- og optoutalternativene kan brukes til å filtrere ut hvilke taster serveren skal spore nøyaktig eller ikke spore. Med disse alternativene aktivert i klientsporingskommandoen, holder Redis bare oversikt over nøklene som er spørsmål like etter klienten Caching Yes -kommandoen. Dette minimerer bruk av serversiden og laster drastisk.
Konklusjon
Oppsummert er caching av klientsiden en av de mye brukte teknikkene for å forbedre ytelsen til webapplikasjoner som ofte ber om data fra back-end databaser. Som diskutert, kan nettleseren eller applikasjonsserveren for klientsiden inneholde dataene relatert til populære spørsmål utstedt av klienten. Som nevnt i introduksjonen, i Redis, kalles hurtigbufring av klientsiden. Videre er de to sporingsmodusene tilgjengelige i Redis. Både de dedikerte klient- og kringkastingsmodusene har egne brukssaker.