Hvis Redis er enkelttrådet, hvorfor så overhovedet have brug for en låsemekanisme.
Redis er faktisk (for det meste) enkelttrådet, men låsning er påkrævet, når flere klienter forsøger at gøre forskellige ting i tilstødende tidsmæssig nærhed. Låsningen diskuteret i RiA handler om præcis det - at sikre, at kun én klient/tråd udfører en bestemt opgave, eller at sikre, at opdateringer ikke går galt.
Her er et eksempel på, hvorfor du har brug for låsning på trods af Redis' enkelttrådede:antag, at du har en værdi i Redis, et tal for eksempel gemt under en nøgle ved navn foo . Din apps kode læser dette nummer (GET foo ), gør noget det (f.eks. tilføjer 1) og skriver det tilbage (SET ). Når du kører din kode i en enkelt tråd, vil det se sådan ud:
App Redis
|---- GET foo ---->|
|<------ 1 --------|
| |
| thinking... |
| |
|--- SET foo 2 --->|
|<----- OK --------|
Lad os nu se, hvad der sker, når to app-klienter prøver at gøre dette:
App 1 Redis App 2
|---- GET foo ---->| |
|<------ 1 --------|<--- GET foo -----|
| |------- 1 ------->|
| thinking... | |
| | thinking...|
|--- SET foo 2 --->| |
|<----- OK --------|<--- SET foo 2 ---|
| |------ OK ------->|
Her kan du med det samme se, hvad der skete uden at låse, på trods af at serveren (for det meste) er enkelttrådet - i stedet for 3, foo 's værdi er 2. Efterhånden som du tilføjer flere tråde/klienter/apps, kan ting gå lystigt og frygteligt galt, når flere forfattere forsøger at ændre dataene uden koordinering (f.eks. låsning).
Optimistisk låsning er blot en af måderne at gøre det på, som Redis tilbyder indbygget via WATCH mekanisme. Nogle gange er optimisme dog - på trods af dens afslappede og glade natur - ikke den rigtige løsning, så du bliver nødt til at implementere bedre/avancerede/forskellige mekanismer for at forhindre løbsforhold. Sådanne låse kunne uden tvivl implementeres selv uden for Redis, men hvis du allerede bruger det, giver det mening også at administrere dine låse i det.