sql >> Database >  >> NoSQL >> Redis

Redis:Race Conditie en Single threaded

Als Redis Single Threaded is, waarom dan überhaupt een vergrendelingsmechanisme nodig hebben.

Redis is inderdaad (meestal) single-threaded, maar vergrendeling is vereist wanneer meerdere clients verschillende dingen proberen te doen in aangrenzende temporele nabijheid. De vergrendeling die in RiA wordt besproken, gaat precies daarover:ervoor zorgen dat slechts één client/thread een specifieke taak uitvoert, of ervoor zorgen dat updates niet misgaan.

Hier is een voorbeeld waarom je ondanks de single-threadedness van Redis vergrendeling nodig zou hebben:neem aan dat je een waarde in Redis hebt, een getal dat bijvoorbeeld is opgeslagen onder een sleutel met de naam foo . De code van je app leest dat nummer (GET foo ), doet het iets (bijv. voegt 1) toe en schrijft het terug (SET ). Als u uw code in één enkele thread uitvoert, ziet deze er als volgt uit:

App               Redis
 |---- GET foo ---->|
 |<------ 1 --------|
 |                  |
 | thinking...      |
 |                  |
 |--- SET foo 2 --->|
 |<----- OK --------|

Laten we nu eens kijken wat er gebeurt als twee app-clients dit proberen:

App 1             Redis              App 2
 |---- GET foo ---->|                  |
 |<------ 1 --------|<--- GET foo -----|
 |                  |------- 1 ------->|
 | thinking...      |                  |
 |                  |       thinking...|
 |--- SET foo 2 --->|                  |
 |<----- OK --------|<--- SET foo 2 ---|
 |                  |------ OK ------->|

Hier kun je meteen zien wat er is gebeurd zonder te vergrendelen, ondanks dat de server (meestal) single-threaded is - in plaats van 3, foo 's waarde is 2. Naarmate u meer threads/clients/apps toevoegt, kunnen dingen vrolijk en vreselijk mis gaan wanneer meerdere schrijvers proberen de gegevens te wijzigen zonder coördinatie (bijv. vergrendeling).

Optimistische vergrendeling is slechts een van de manieren om dat te doen, die Redis ingebouwd biedt via de WATCH mechanisme. Soms is optimisme - ondanks het gemakkelijke en vrolijke karakter - echter niet de juiste oplossing, dus moet je betere/geavanceerde/andere mechanismen implementeren om race-omstandigheden te voorkomen. Dergelijke sloten zouden zelfs buiten Redis kunnen worden geïmplementeerd, maar als je het al gebruikt, is het logisch om je sloten er ook in te beheren.




  1. Applicaties voor MongoDB en Redpanda ontwikkelen met Docker Compose

  2. MongoDB en PostgreSQL-gedachten

  3. Hoe de verbinding met mongodb te controleren

  4. Hoe Apache CouchDB op CentOS 8 te installeren