Cache-invalidering in PHP bestaat niet uit het kiezen van een TTL en het opslaan van antwoorden in Redis. Het is een beslissing over consistentie: bepalen welke informatie vertraagd mag zijn, hoe lang en wat er moet gebeuren wanneer de oorspronkelijke gegevens veranderen. Een slecht ontworpen cache kan een oude prijs tonen, toegang verlenen met ingetrokken permissies of beschikbaarheid presenteren die niet meer bestaat. Een te conservatieve cache daarentegen verplaatst alle belasting naar de database en verliest haar doel.
Het uitgangspunt is om elk item te behandelen als gegevens met een gedefinieerde eigenaar, levenscyclus en risico. Hierdoor kunnen product, business en technologie afspreken wanneer een mogelijk verouderde lezing acceptabel is en wanneer de actuele status uit de bron van waarheid moet worden opgehaald.
Classificeer gegevens voordat u ze in de cache plaatst
Niet alle veelgebruikte gegevens moeten worden gecachet en ook niet alle gegevens verdragen hetzelfde mechanisme. Beoordeel elke lezing aan de hand van vier criteria: volatiliteit, impact van veroudering, kosten van het raadplegen van de bron en tolerantie voor een cachefout.
- Lage volatiliteit en lage impact: openbare catalogi, metadata of niet-gevoelige configuraties verdragen doorgaans TTL's van minuten of uren, afhankelijk van hun wijzigingsproces.
- Gemiddelde volatiliteit: productdetails, dashboardaggregaten en zoekresultaten kunnen worden gecachet als ze worden geïnvalideerd wanneer de records waaruit ze bestaan veranderen.
- Hoge impact: permissies, saldi, limieten, transactionele statussen, voorraad tijdens de bevestiging van een aankoop en autorisatiecontroles vereisen een consistente bron van waarheid of een expliciete, zeer strikte versheidsstrategie.
- Gegevens die kostbaar zijn om te berekenen: rapporten en afgeleide samenvattingen kunnen caching rechtvaardigen, ook als ze niet vaak worden geraadpleegd, maar moeten aangeven welke entiteiten hen invalideren.
Het is nuttig om presentatiecache te scheiden van beslissingscache. Het gedurende enkele seconden tonen van de vorige naam van een categorie kan aanvaardbaar zijn. Een oud beleid gebruiken om een handeling te autoriseren is dat doorgaans niet. Raadpleeg voor kritieke beslissingen de gezaghebbende bron of sla versies op die vóór de handeling kunnen worden geverifieerd.
Definieer eigenaarschap, sleutels en versheidscontracten
Elk item heeft een operationeel overzicht nodig. Daarin moeten de bron van waarheid, de sleutel, de afnemers, de maximale TTL, de invalidatiegebeurtenis, het gedrag als Redis niet beschikbaar is en de functionele of technische eigenaar staan. Zonder dit contract vermenigvuldigen de sleutels zich en weet niemand wat na een wijziging moet worden verwijderd.
Gebruik voorspelbare sleutels met voldoende bereik. Bijvoorbeeld: product:42 vertegenwoordigt een concrete entiteit; tenant:8:product:42 voorkomt het mengen van gegevens tussen organisaties; en dashboard:tenant:8:period:current identificeert een afgeleid resultaat. Neem geen geheime gegevens op in sleutels en gebruik geen instabiele serialisaties als identiteit.
Het is ook raadzaam om een uniform waardeformaat te behouden: payload, versie of aanmaakdatum en, wanneer relevant, een versheidsindicator. Een afnemer mag niet aannemen dat een gecachet antwoord gelijkwaardig is aan een transactioneel consistente lezing.
final class ProductCacheKey
{
public static function detail(int $tenantId, int $productId): string
{
return "tenant:{$tenantId}:product:{$productId}:v1";
}
}Het schemasuffix maakt het mogelijk de structuur van de waarde te wijzigen zonder alle historische items te hoeven lokaliseren en verwijderen. Het vervangt de invalidatie van bedrijfsgegevens niet, maar vermindert risico's tijdens een formaatevolutie.
Kies het updatepatroon op basis van het type lezing
Cache-aside voor herbruikbare leesbewerkingen
Met cache-aside zoekt de applicatie eerst naar de sleutel; bij afwezigheid raadpleegt zij de database, bouwt de waarde op en slaat die met TTL op. Dit is eenvoudig en geschikt voor relatief stabiele leesbewerkingen. De beperking is duidelijk: na een schrijfbewerking moet iemand de betreffende items verwijderen of vervangen.
Invalidatie moet na het bevestigen van de transactie plaatsvinden. Verwijderen vóór de commit kan ertoe leiden dat een ander proces de cache opnieuw opbouwt met de nog oude waarde. Als de applicatie events publiceert, helpt een outbox-patroon om de wijziging in dezelfde transactie vast te leggen en de invalidatieopdracht vervolgens betrouwbaar af te leveren.
Expliciete update en versionering
Als een entiteit zeer vaak wordt gelezen en de wijzigingen ervan gecontroleerd zijn, kan het item na het bevestigen van de schrijfbewerking worden bijgewerkt. Zo wordt de volgende cachemisser vermeden. Het proces moet echter exact dezelfde representatie genereren als lezers verwachten; anders is invalideren en opnieuw opbouwen doorgaans minder risicovol.
Versionering van sleutels is nuttig voor brede afhankelijkheden. In plaats van alle productlijsten van een organisatie te verwijderen, wordt tenant:8:products:version verhoogd en nemen de lijsten dat nummer op in hun sleutel. Oude lijsten verlopen vanzelf. Deze aanpak beperkt massale verwijderingen, maar vereist controle over de groei van sleutels en mag niet worden gebruikt om een slecht begrepen afhankelijkheid te verbergen.
Beheers races en afgeleide afhankelijkheden
De typische race verloopt als volgt: een lezing mist de cache en vraagt de oude waarde op; een schrijfbewerking wordt bevestigd en invalideert; de eerste lezing eindigt en slaat de oude waarde opnieuw op. Combineer voor gevoelige gegevens invalidatie met entiteitsversionering of een korte vergrendeling voor heropbouw. Controleer vóór het schrijven van de berekende waarde of de geraadpleegde versie nog steeds de huidige is. Is dat niet zo, verwerp dan het resultaat en lees opnieuw.
Gedistribueerde vergrendelingen moeten kort zijn, een vervaldatum hebben en geen centraal blokkadepunt worden. Hun functie is gelijktijdige heropbouwen te beperken, niet om op zichzelf bedrijfsconsistentie te waarborgen. Als de vergrendeling niet wordt verkregen, is een optie om kort te wachten op de opnieuw opgebouwde waarde of een beperkte directe lezing toe te staan.
Invalidatie op basis van afhankelijkheden vereist een inventaris. Een productwijziging kan invloed hebben op de details ervan, meerdere lijsten, zoekresultaten, tellers en een dashboard. Een rolwijziging kan invloed hebben op de effectieve permissies van gebruikers en afgeleide menu's. Modelleer deze relaties expliciet:
- Invalideer de directe entiteit via haar sleutel.
- Invalideer of versioneer de collecties en aggregaten die ervan afhankelijk zijn.
- Herbereken kostbare resultaten asynchroon als de gebruikerservaring dit toestaat.
- Verwar het wissen van een weergave niet met het bijwerken van de bron van waarheid.
Wanneer de relatie niet eenvoudig opsombaar is, is een versienaamruimte per organisatie, catalogus of beleid doorgaans veiliger dan proberen alle getroffen sleutels te ontdekken met globale verwijderpatronen.
Gebruik TTL, jitter en limieten om de bron te beschermen
De TTL is een veiligheidsnet, niet het enige coherentiemechanisme. Zelfs een correct geïnvalideerde sleutel moet verlopen: er kunnen fouten in de aflevering van events, fouten bij deployments of verweesde items zijn. Kies de TTL op basis van de kosten van de fout, niet alleen op basis van de kosten van de query.
Pas willekeurige jitter toe op de TTL zodat duizenden gelijktijdig aangemaakte sleutels niet tegelijkertijd verlopen. Bescherm bovendien de bron tegen een lawine van cachemissers door een vergrendeling voor heropbouw per sleutel, gelijktijdigheidslimieten en quota per afnemer. Voor niet-kritieke gegevens kan een licht verlopen waarde worden geserveerd terwijl één proces deze herberekent; voor permissies of beslissingskritieke beschikbaarheid moet die techniek worden verworpen of beperkt tot uitdrukkelijk goedgekeurde scenario's.
Ontwerp degradatie voor wanneer Redis uitvalt
Redis is een operationele afhankelijkheid, niet de bron van waarheid. Als Redis niet reageert, heeft de applicatie een gedefinieerde degradatiemodus nodig. Voor een goedkope openbare lezing kan zij de database rechtstreeks met time-outs raadplegen. Voor dure query's is het raadzaam load shedding toe te passen, velden te beperken, met een tijdelijk niet-beschikbare status te antwoorden of een geschikte replica te gebruiken als de architectuur daarin voorziet.
Maak van een cachefout geen uitputting van databaseverbindingen. Definieer korte time-outs, circuit breakers, querybudgetten en meetwaarden per route. Bij kritieke gegevens is het beter een handeling te weigeren dan een beslissing te nemen met permissies, saldi of voorraad waarvan de versheid niet kan worden gegarandeerd.
Test en observeer versheid, niet alleen treffers
Een hoog trefferspercentage bewijst niet dat de cache correct is. Instrumenteer treffers, missers, latentie, lees- en schrijffouten, resterende TTL, vergrendelingen voor heropbouw, uitgevoerde en mislukte invalidaties, naast query's en databaseverzadiging. Koppel deze signalen aan elke sleutelfamilie en niet alleen aan Redis als globale service.
Dek in tests ten minste de initiële lezing, de daaropvolgende update, de verwijdering, de invalidatie na commit, de cache-uitval en de races tussen lezer en schrijver af. Verifieer dat een gebruiker toegang verliest nadat een permissie is ingetrokken, dat een lijst een wijziging weerspiegelt volgens haar versheidscontract en dat een mislukte invalidatie waarschuwingen of herstel activeert.
Checklist voor een bestaande PHP-applicatie
- Inventariseer de herhaalde leesbewerkingen en classificeer ze op risico, volatiliteit en kosten.
- Leg voor elk gegeven de bron van waarheid en de maximale tolerantie voor veroudering vast.
- Documenteer sleutels, TTL, afhankelijkheden, afnemers en invalidatiegebeurtenis.
- Voer invalidaties of updates alleen uit na de bevestigde commit.
- Bescherm gelijktijdige heropbouwen en voeg jitter toe aan relevante vervalwaarden.
- Definieer de degradatiemodus bij onbeschikbaarheid van Redis zonder de database te overbelasten.
- Meet versheid en invalidaties, niet alleen het trefferspercentage.
- Controleer periodiek sleutels zonder eigenaar, buitensporige TTL's en niet-afgedekte afhankelijkheden.
Een betrouwbare strategie voor cache-invalidering in PHP maakt haar afwegingen zichtbaar: wat verouderd mag raken, gedurende welk interval, hoe dit wordt gecorrigeerd en wat er gebeurt wanneer een component faalt. Die duidelijkheid is waardevoller dan zonder onderscheid een cache toe te voegen.
