Redis-välimuisti- ja jonokuormat Dockupissa

Redis-välimuisti- ja jonokuormat voivat käyttää samaa hallinnoitua Redis-palvelua, mutta niiden oikeellisuusvaatimukset eroavat toisistaan. Välimuisti voidaan yleensä rakentaa uudelleen tietojen hävitessä. Jono voi puolestaan sisältää töitä, joita ei saa hiljaisesti hylätä tai käsitellä kahdesti.

Dockup ottaa Redisin käyttöön hallinnoituna tietokantana, tarjoaa koon ja lokien tarkastelutoiminnot, tukee varmuuskopiointi- ja solmusiirtotyönkulkuja sekä voi yhdistää tietokannan sovelluspalveluihin projektin sisäisen yksityisen verkon kautta.

Miten hallinnoitu Redis otetaan käyttöön?

Luo Redis valittuun workspaceen:

dockup db create \
  --name app-redis \
  --type redis \
  --json

Vahvista tietokannan kohde:

dockup db list --json

Tallenna palautetut yhteystiedot lähdekoodivaraston ulkopuolelle ja liitä ne käyttävään palveluun secret-muuttujana:

dockup env set REDIS_URL="$REDIS_URL" \
  --secret \
  -s production/api \
  --json

dockup deploy production/api --wait --json

Uudelleenkäyttöönotto luo uuden sovelluskontin, jossa päivitetty ympäristö on käytössä. Vanhan kontin uudelleenkäynnistys ei ota käyttöön äskettäin tallennettua haluttua arvoa.

Käytä erillisiä Redis-tietokantoja tai -instansseja, kun välimuistin eviction-käyttäytyminen ja kriittisen jonon säilytys eivät saa kilpailla samasta muistista. Eristäminen helpottaa myös häiriöiden selvittämistä ja käyttöoikeuksien hallintaa.

Milloin Redisiä kannattaa käyttää välimuistina?

Välimuisti vähentää toistuvaa työtä tai viivettä tallentamalla johdettua dataa. Totuuden lähde säilyy muualla, yleensä PostgreSQLissä, MySQLissä, MongoDB:ssä, ulkoisessa API:ssa tai deterministisessä laskennassa.

Hyvä välimuistisuunnittelu määrittelee:

• Välimuistiavaimen muodon ja namespacen.
• TTL-arvon.
• Suurimman hyväksyttävän vanhentuneisuuden.
• Invalidoinnin käynnistimen.
• Toiminnan cache miss -tilanteessa.
• Toiminnan, kun Redis ei ole käytettävissä.
• Suojauksen thundering herd -ilmiöltä.
• Mitä tietoja ei saa koskaan tallentaa välimuistiin.

Häiriö	Turvallinen välimuistin toiminta
Avain puuttuu	Laske uudelleen tai lue totuuden lähteestä
Redis ei ole käytettävissä	Siirry lähteeseen ja suojaa sitä rate limiting -mekanismilla
Vanhentunut merkintä	Vanhenna tai invalidoi
Serialisointimuutos	Versioi key namespace
Muistipaine	Poista ensin uudelleen rakennettavissa oleva data
Hot key	Lisää local cache, sharding tai request coalescing

Älä tee koko sovellusta käytettäväksi kelpaamattomaksi vain siksi, että valinnainen välimuisti on alhaalla. Käytä rajattuja timeouteja ja fallback-polkuja. Älä kuitenkaan piilota kaikkia vikoja: pitkäkestoinen välimuistihäiriö voi ylikuormittaa lähdetietokannan.

Mitä muuttuu, kun Redisiä käytetään työjonona?

Jono edustaa odottavaa työtä, joten sovelluksen on määriteltävä toimitus- ja palautumissema­tiikka. Redis itsessään on tietorakenteiden palvelin; takuut riippuvat jonokirjastosta ja worker-protokollasta.

Päätä seuraavat asiat:

1. Milloin työ katsotaan vastaanotetuksi?
2. Milloin siitä lähetetään kuittaus?
3. Mitä tapahtuu, jos worker kaatuu suoritettuaan sivuvaikutuksen mutta ennen kuittausta?
4. Miten retry-yrityksiä viivästetään ja rajoitetaan?
5. Minne pysyvästi epäonnistuneet työt siirretään?
6. Miten duplikaattisuoritukset tehdään turvallisiksi?
7. Miten jonon pituutta seurataan?
8. Voidaanko työn payload rakentaa uudelleen?

Rakenna workerit idempotenteiksi. Maksun veloitus, sähköposti tai datan tuonti voidaan toimittaa useammin kuin kerran häiriön jälkeen. Käytä liiketoimintatason idempotency key -avainta ja tallenna suorituksen valmistuminen totuuden lähteenä toimivaan tietokantaan.

Erota jonojen nimet kuorman ja prioriteetin mukaan. Hidas mediaan liittyvä työ ei saa estää salasanan palautusta tai webhookien käsittelyä. Vältä salaisuuksien sijoittamista job payloadeihin, jos viitetunnus riittää.

Redis-välimuisti- ja jonodeploy­mentin tulisi dokumentoida, mitkä avaimet ovat hävitettävissä ja mitkä edustavat liiketoimintatason työtä.

Miten yksityinen verkko yhdistää palvelut Redisiin?

Ota projektiverkko käyttöön:

dockup network enable production --json

Redis-palveluun pääsee samassa projektissa olevista palveluista sen vakaan <slug>.internal-hostname-tunnuksen kautta. Ota sovellus uudelleen käyttöön, jotta Dockup voi injektoida sisäiset yhteysmuuttujat.

Jos haluat tehdä Redisistä vain yksityisessä verkossa käytettävän:

dockup db private production/app-redis --json

Palauta julkinen kuuntelija tarvittaessa:

dockup db private production/app-redis --off --json

Yksityinen verkko poistaa julkisen internet-reitin saman projektin sisäiseltä liikenteeltä, mutta se ei korvaa autentikointia. Pidä Redisin yhteystiedot salaisina ja rajoita, mitkä palvelut saavat ne käyttöönsä.

Eri projektit eivät pääse toistensa yksityisiin verkkoihin. Tästä rajasta on hyötyä esimerkiksi silloin, kun tuotanto ja staging eivät saa jakaa välimuistiavaimia tai jonotöitä.

Katso yksityinen verkkoyhteys ja sisäiset domainit saadaksesi täydellisen kuvauksen mallista.

Miten Redis-häiriöiden pitäisi vaikuttaa sovellukseen?

Luokittele työkuorma ennen palautumiskoodin kirjoittamista.

Työkuorma	Häviön sietokyky	Toiminta häiriössä
HTML-fragmentin välimuisti	Korkea	Rakenna lähteestä uudelleen
Session store	Matala–keskitasoinen	Käyttäjät voidaan kirjata ulos; suunnittele fallback
Rate limit -laskurit	Käytännöstä riippuva	Määritä eksplisiittisesti, sallitaanko vai estetäänkö liikenne
Työjono	Matala	Lopeta uusien töiden vastaanotto tai tallenna ne muualle
Distributed lock	Kriittisissä osioissa erittäin matala	Käytä fencing- tai idempotency-mekanismia
Feature cache	Korkea	Käytä oletusarvoa tai lähdettä

Välimuistiasiakas ei saa yrittää uudelleen loputtomasti. Pitkät uudelleenyritykset voivat kuluttaa kaikki sovelluksen workerit ja muuttaa Redis-häiriön täydelliseksi käyttökatkokseksi. Jonoworkerien tulee hidastaa uudelleenyrityksiä, tuoda epäonnistuneet työt näkyviin ja lopettaa yritykset määritellyn käytännön mukaisesti.

Tarkastele Redisin kokoa ja käyttävän sovelluksen runtime-lokeja:

dockup db size production/app-redis --json
dockup logs production/api --json

Kasvava koko voi viitata puuttuviin vanhenemisiin, hallitsemattomasti kasvavaan jonoon, liian suuriin payloadeihin tai hylättyihin namespaceihin. Älä pidä tietokannan uudelleenkäynnistystä ensimmäisenä vastauksena sovelluksen timeouteihin, vaan tarkista ensin konfiguraatio, verkkoyhteys ja asiakaskirjaston toiminta.

Miten varmuuskopiointi, siirrot ja monitorointi liittyvät Redisiin?

Dockup tarjoaa hallinnoidun tietokannan varmuuskopiointityönkulun:

dockup db backups production/app-redis --json
dockup db backup production/app-redis --json

Se, täyttääkö Redis-varmuuskopio työkuorman palautumistavoitteen, riippuu datan merkityksestä. Välimuistin varmuuskopio voi olla tarpeeton. Jonon varmuuskopiosta voi silti puuttua varmuuskopiohetken jälkeen vastaanotettuja töitä. Liiketoimintakriittisillä töillä tulisi mahdollisuuksien mukaan olla palautettavissa oleva lähdetietue jonon ulkopuolella.

Siirrä Redis solmusta toiseen komennolla:

dockup db migrate production/app-redis \
  --node <nodeId> \
  --json

Suunnittele siirron vaikutukset asiakkaisiin ja workereihin. Varmista ennen tuotantoa, että uudelleenyhdistäminen, retry-toiminta ja idempotency-käyttäytyminen toimivat.

Seuraa tietokannan koon lisäksi sovellustason mittareita:

• Välimuistin osumatarkkuus.
• Miss-tilanteen viive.
• Eviction-tapahtumat.
• Jonon pituus ja vanhimman työn ikä.
• Töiden onnistumis-, retry- ja epäonnistumismäärät.
• Workereiden rinnakkaisuus.
• Redisin yhteysvirheet.
• Payloadin koko.

Dockup mittaa suorittimen, RAM-muistin ja levyn kulutusta minuutti kerrallaan suhteessa planin saldoon. Suositeltu Pro-plan maksaa 20 dollaria kuukaudessa ja sisältää 20 dollarin käyttöhyvityksen, mutta kapasiteettipäätösten tulisi perustua työkuorman mittareihin, ei planin nimeen.

Millainen on turvallinen Redisin tuotantotarkistuslista?

Varmista ennen käyttöönottoa:

1. Täsmällinen project/db-kohde.
2. Välimuistin ja jonon vastuut on dokumentoitu.
3. Yhteys-URL on peitetty secret.
4. Yksityisen verkon käytäntö on päätetty.
5. Jokaisella välimuistilla on TTL tai eksplisiittinen invalidointi.
6. Jonoworkerit ovat idempotentteja.
7. Retry- ja dead-letter-toiminta on määritelty jonojärjestelmässä.
8. Koko- ja jononpituushälytykset ovat käytössä.
9. Varmuuskopion arvo ja rajoitukset tunnetaan.
10. Uudelleenkäynnistys ja siirto edellyttävät hyväksyntää.

Esimerkki välimuistin ja jonon erottelusta

Pieni sovellus voi aloittaa yhdellä Redis-tietokannalla, jos riski on pieni, mutta käytä selkeitä avainprefiksejä:

cache:user-profile:v2:<user-id>
cache:catalog:v5:<product-id>
queue:email:waiting
queue:email:active
lock:invoice:<invoice-id>

Kun työkuorma kasvaa, erota kriittinen jonotila aggressiivisesti evictattavasta välimuistista. Tämä on operatiivinen raja, ei vain nimeämiseen liittyvä mieltymys.

Onnistunut Redis-välimuisti- ja jonoratkaisu tekee sovelluksen toiminnasta ennakoitavaa silloin, kun Redis on nopea, hidas, tyhjä tai poissa käytöstä.

Katso relaatiotietokannan totuuden lähteenä toimivat toiminnot kohdasta hallinnoitu PostgreSQL. Laajempiin kapasiteettivalintoihin löydät tietoa artikkelista tietokantojen skaalausstrategiat. Katso ajantasaiset tietokantakomennot Dockup CLI -referenssistä.

Määritä avainten ja payloadien evoluutio

Välimuisti- ja jonodata säilyy yksittäistä sovellusprosessia pidempään. Uusi julkaisu voi lukea edellisen julkaisun kirjoittamia avaimia blue-green-siirtymän aikana. Versioi key namespacet ja job payloadit, jotta molemmat versiot voivat toimia rinnakkain.

Sisällytä jonoissa payloadeihin versio ja pidä workerit kykenevinä käsittelemään vähintään niitä versioita, joita jonossa saattaa vielä odottaa. Käyttöönoton rollback voi palauttaa vanhan koodin, vaikka uuden muodon jobit ovat jo Redisissä. Ilman yhteensopivuutta sovelluksen palautus voi lisätä virheitä.

Testaa resurssipaine tarkoituksella

Testaa ei-tuotantoympäristössä puuttuvia avaimia, hitaita Redis-vastauksia, yhteyksien nollaamista, jonon kertymistä, duplikaattitoimituksia sekä täyttä tai lähes täyttä muistia. Tarkkaile, salliiko vai estääkö sovellus liikenteen häiriötilanteessa, yrittääkö se uudelleen tai ylikuormittaako se toista riippuvuutta.

Redis-välimuisti- ja jonoratkaisun runbookissa tulee määrittää rajat retry-yrityksille ja rinnakkaisuudelle. Rajattomat retry-silmukat voivat kuluttaa kaikki workerit ja vaikeuttaa palautumista alkuperäistä häiriötä enemmän.

Säilytä palautuspolku totuuden lähteeseen

Tallenna kriittisiä töitä varten ensisijaiseen tietokantaan riittävästi tilaa, jotta työ voidaan rakentaa uudelleen Redisin tietojen hävitessä. Jonon tulisi nopeuttaa käsittelyä, ei muodostua ainoaksi merkinnäksi siitä, että asiakkaan toiminto tapahtui.

Aloita todennettavalla käyttöönotolla

Ota Redis käyttöön ei-tuotantoprojektissa, testaa välimuistin fallback ja duplikaattitöiden toimitus sekä määrittele häiriötilannekäytäntö eksplisiittisesti ennen kriittisten töiden reitittämistä.

Aloita maksutta osoitteessa app.dockup.ai. Free-plan maksaa 0 dollaria kuukaudessa, sisältää 10 dollarin aloitushyvityksen ja tukee yhtä workspacea, kolmea tietokantaa ja kolmea käyttöönottoa.

Usein kysytyt kysymykset

Voiko Dockup luoda hallinnoidun Redisin?

Kyllä. Käytä hallinnoidun tietokannan luontikomentoa tyypillä redis ja yhdistä sovellus käyttämällä palautettuja yhteystietoja, jotka on tallennettu secretiin.

Pitäisikö välimuisti- ja jonodatan jakaa yksi Redis-instanssi?

Pienen ja vähäriskisen työkuorman tapauksessa näin voidaan tehdä, mutta erottelu on turvallisempaa, kun välimuistin eviction-käyttäytymisellä ja kriittisen jonon säilytyksellä on erilaiset saatavuus- ja muistivaatimukset.

Takaako Redis, että jonossa oleva työ suoritetaan täsmälleen kerran?

Yleistä exactly-once-takuuta ei pidä olettaa. Toimituksen semantiikka riippuu jonokirjastosta ja workerin suunnittelusta, joten sivuvaikutukset tulee tehdä idempotenteiksi.

Voiko Redis käyttää Dockupin yksityistä verkkoa?

Kyllä. Ota projektiverkko käyttöön, ota käyttävät palvelut uudelleen käyttöön sisäisten muuttujien saamiseksi ja tee Redis-tietokannasta tarvittaessa vain yksityisessä verkossa käytettävä.

Riittääkö Redisin varmuuskopio kriittiselle työjonolle?

Ei välttämättä. Se kuvaa yhtä ajankohtaa, eikä se välttämättä sisällä uudempia vastaanotettuja töitä. Säilytä palautettavissa olevat lähdetietueet ja määrittele sovellustason työjonon palautus.