Na het overschakelen naar twee webservers verbreken gebruikers willekeurig de verbinding. De oorzaak: een enkele Redis geconfigureerd op maxmemory-policy allkeys-lru, waarbij de cache session:* sleutels onder belasting verwijdert. Het team had Redis “toegevoegd” zonder te kiezen welke rol het speelt in de architectuur.
Dit scenario herhaalt zich zodra een effectief instrument als generieke oplossing wordt ingezet. Redis is een in-memory-engine voor algemeen gebruik - geen enkel product met één standaardmodus. Cache, sessieopslag en berichtenmakelaar delen het protocol, maar niet de duurzaamheids- of uitzettingsvereisten.
Redis versnelt wat u besluit in het geheugen op te slaan. Als het slecht is geconfigureerd, versnelt het ook uw incidenten: enorme verbroken verbindingen, nooit verzonden e-mails, verouderde gegevens die urenlang worden bewaard. De preliminaire vraag is dus niet “hebben we Redis nodig?” » maar “welke taak moet Redis bieden – en met welke regels als het geheugen verzadigd raakt? »
Drie toepassingen — drie contracten
Elk gebruik legt een ander contract op tussen volatiliteit, uitzetting en volharding.
| Gebruik | Volatiliteit OK | Uitzetting | Volharding |
|---|---|---|---|
| Objectcache | Ja | LRU/LFU vaak | Nee |
| Gebruikerssessie | Nee | no-uitzetting of speciaal exemplaar | AOF aanbevolen |
| Wacht | Nee | geen uitzetting | AOF + vrijspraak werknemers |
Cache — SQL-queryresultaten, HTML-fragmenten, snelheidsbeperkende tellers. Herberekenbaar als het ontbreekt.
Sessies — winkelwagen, PHP/Laravel/Symfony-verbinding, token-zwarte lijst. Verdwijning = catastrofale ervaring.
Wachtrij — Laravel Horizon, Sidekiq, Bull: e-mails, thumbnails. Verlies = berichten zijn nooit achtergelaten.
Een Redis die sessies verwijdert om ruimte vrij te maken voor cache is een architecturale bug, geen verfijning.
Integratiepatronen
PHP/Laravel — configureer SESSION_DRIVER=redis en CACHE_DRIVER=redis met twee afzonderlijke verbindingen en afzonderlijke voorvoegsels (app_session:, app_cache:).
Node — gebruik connect-redis voor express-sessie en ioredis voor cache met expliciete TTL op elke sleutel.
Werknemers — plaats consumenten op processen die los staan van internet; dezelfde Redis voor de wachtrij, horizontale schaalvergroting van werknemers.
TTL-cache — stel altijd een levensduur in; vermijd verweesde sleutels zonder vervaldatum.
Voor de onderliggende SQL-laag, zie MySQL voor dynamische site. Als u twijfelt tussen managed hosting en dedicated server, helpt de gids PaaS of server om Redis in het geheel te situeren.
Maatvoering en hoge beschikbaarheid
Grootte van het RAM: datasetgrootte plus twintig tot dertig procent marge, inclusief wachtrijpieken. Geen ruil op Redis: de latentie wordt explosief. Voor kritieke sessies met meerdere knooppunten kunt u Redis Sentinel of een beheerd aanbod (ElastiCache, Scaleway, OVH) overwegen. Maak een back-up van bestanden met AOF; de cache kan opnieuw worden opgebouwd.
Vergelijk beheerde Redis-aanbiedingen in onze overzicht.
Veelvoorkomende fouten
Opnieuw getoond op internet — poort 6379 zonder authenticatie leidt vaak tot cryptocurrency-mining.
Sleutels zonder naamruimte: botsing tussen staging en productie.
*KEYS in productie** — blokkeert de hele server.
Cache zonder ongeldigverklaring — verouderde gegevens na bedrijfsupdate.
Wachtrij zonder dode wachtrij — opdrachten gaan geruisloos verloren.
De bovenkant: Redis versnelt - het patcht niet
Profileer SQL en sessies voordat u vier gigabyte beheerde Redis aanschaft. Meet ook het uitzettingspercentage na een week van echte belasting: een cache die elk uur nuttige sleutels uitzet, duidt vaak op onvoldoende geheugengrootte of een slecht gekozen uitzettingsbeleid voor de toegewezen rol.
Beslis en ga vooruit zonder blinde vlek
Identificeer eerst de werkelijke behoefte (sessie met meerdere servers, objectcache, wachtrij of combinatie) en scheid vervolgens instanties en uitzettingsbeleid per rol. Configureer authenticatie, bind Redis aan het particuliere netwerk en weiger publieke blootstelling. Houd het geheugen en de uitzettingen in de gaten en documenteer de ongeldigverklaringsregels voor de zakelijke cache voordat u de architectuur als stabiel beschouwt.
Veelgestelde vragen
Opnieuw is vereist om mijn site te versnellen?
Nee. Begin met HTTP-cache, OPcache en geoptimaliseerde SQL-query's. Redis wordt relevant wanneer u gedeelde sessies met meerdere servers, zware objectcaching of asynchrone wachtrijen nodig heeft.
Cache en sessie op dezelfde Redis?
Niet aanbevolen in productie: het cache-verwijderingsbeleid kan sessiesleutels verwijderen. Scheid exemplaren of logische bases met het juiste beleid.
Moeten we Redis-persistentie inschakelen?
Voor een pure cache vaak niet. Voor sessies of wachtrijen: ja: AOF of beheerde Redis met back-up.
Redis beheerd of op VPS?
Kies voor beheerd als hoge beschikbaarheid, back-ups en beveiligingspatches uw vaardigheden te boven gaan. Een VPS is geschikt voor bescheiden verkeer met strenge geheugenmonitoring.
Redis: kies eerst welk bedrijf (cache, sessie of bestand) voordat u een catch-all-instantie installeert.