Het gebruik van Redis-cache verbetert de prestaties en efficiëntie van applicaties aanzienlijk, vooral voor gegevensquery's. Maar tegelijkertijd brengt het ook problemen met zich mee. Een van hen is het belangrijkste probleem de consistentie van data, die strikt onoplosbaar is. Als dataconsistentie vereist is, kan caching niet worden gebruikt.
Andere veelvoorkomende problemen zijn cachepenetratie, cachelawine en cache-doorbraak. Op dit moment zijn er ook populairdere oplossingen in de industrie. Dit artikel is niet bedoeld om deze drie problemen perfecter op te lossen, noch om de populaire oplossingen in de industrie te ondermijnen. In plaats daarvan zullen we deze drie probleemfenomenen demonstreren uit de daadwerkelijke codebewerking. De reden hiervoor is dat het moeilijk is om een heel levendig concept in het hoofd te hebben door alleen maar naar de academische uitleg van deze problemen te kijken, en met daadwerkelijke codedemonstraties kun je je begrip en begrip van deze problemen verdiepen.
Cachepenetratie
Cachepenetratie verwijst naar het opvragen van gegevens die niet in een database bestaan. Als de sleutel niet bestaat of de sleutel is verlopen, wordt de database geraadpleegd en worden de geraadpleegde objecten in de cache geplaatst. Als het databasequery-object leeg is, wordt het niet gecached.
Codeflow
- parameter geef de primaire sleutel-ID van het object door
- Haal het object uit de cache op basis van de sleutel
- Als het object niet leeg is, keert het direct terug
- Als het object leeg is, voer dan een databasequery uit
- Als het object dat uit de database wordt geraadpleegd niet leeg is, plaats het dan in de cache (stel de vervaldatum in). Stel je deze situatie voor: wat zou er gebeuren als de doorgegeven parameter -1 was? Deze -1 is een object dat niet mag bestaan. De database wordt elke keer geraadpleegd, elke query is leeg en wordt niet elke keer gecachet. Als er een kwaadaardige aanval is, kan deze kwetsbaarheid worden uitgebuit om druk op de database te zetten of zelfs te overweldigen. Zelfs als UUID wordt gebruikt, is het makkelijk om een niet-bestaande KEY te vinden en aan te vallen.
In mijn werk gebruik ik de methode van het cachen van nullwaarden, dat wil zeggen stap 5 in het [codeproces], als het object dat uit de database wordt bevraagd leeg is, wordt het ook in de cache geplaatst, maar de vervaldatum van de set cache is kort, bijvoorbeeld door deze op 60 seconden te zetten.
Cache avalanche
Cache-avalanche verwijst naar het verlopen van de cache-set gedurende een bepaalde periode.
Een van de redenen voor de lawine is bijvoorbeeld dat bij het schrijven van dit artikel het binnenkort om nul uur op de twaalfde dag zal zijn, en er zal binnenkort een golf van haastaankopen komen. Dan verloopt om één uur 's nachts de voorraad van deze lading goederen. De toegangszoekopdracht voor deze batch goederen valt op de database, en voor de database zullen er periodieke drukpieken zijn.
Wanneer Xiaobian e-commerceprojecten doet, neemt hij meestal verschillende categorieën goederen aan en slaat hij verschillende cycli op. Goederen in dezelfde categorie, plus een willekeurige factor. Op deze manier kan de cache-vervaltijd zo veel mogelijk worden verspreid, is de cachetijd van producten in populaire categorieën langer, en de cachetijd van producten in niet-populaire categorieën is korter, wat ook de middelen van de cachingdienst kan besparen.
In feite is gecentraliseerde vervaldatum niet erg fataal, en de nog fataalste cache-lawine is dat een node van de cacheserver uitvalt of de verbinding verbreekt. Omdat de cachelawine die van nature optreedt binnen een bepaalde periode moet worden gecreëerd, kan de database de druk weerstaan, en op dat moment kan de database ook de druk weerstaan. Het is niets meer dan periodieke druk op de database. De downtime van de cacheservice-node veroorzaakt onvoorspelbare druk op de databaseserver en zal waarschijnlijk de database in een oogwenk overweldigen.
Cache-uitsplitsing
Cache-breakdown verwijst naar een sleutel die zeer heet is, voortdurend een grote gelijktijdigheid heeft; grote gelijktijdigheid concentreert zich op het bereiken van dit punt; wanneer deze sleutel faalt, breekt een continue grote gelijktijdigheid door de cache en vraagt direct naar de database, net als het boren van een gat in een barrière.
Toen Xiaobian e-commerceprojecten deed, maakte hij dit product tot een "hit".
In feite is het in de meeste gevallen moeilijk om zo'n explosie op de databaseserver te zetten. Er zijn maar weinig bedrijven die dit niveau hebben bereikt. Daarom heeft de pragmatische editor de hoofdproducten vroeg voorbereid, zodat de cache nooit verloopt. Zelfs als sommige producten zichzelf fermenteren tot hits, kunnen ze als nooit verlopend worden ingesteld.
De hoofdweg is eenvoudig, en het mutex key mutual rejection lock wordt eigenlijk niet gebruikt.
|
Geplaatst op 19-11-2019 09:55:04
|
|
|
|
