Om Redis är enkelgängad, varför behöver du då en låsmekanism överhuvudtaget.
Redis är verkligen (för det mesta) entrådig men låsning krävs när flera klienter försöker göra olika saker i angränsande temporal närhet. Låsningen som diskuteras i RiA handlar om just det - att se till att bara en klient/tråd gör en specifik uppgift, eller att se till att uppdateringar inte går snett.
Här är ett exempel på varför du skulle behöva låsning trots Redis enkeltrådighet:anta att du har ett värde i Redis, ett nummer till exempel lagrat under en nyckel som heter foo . Din app kod läser det numret (GET foo ), gör något det (t.ex. lägger till 1) och skriver tillbaka det (SET ). När du kör din kod i en enda tråd, så här skulle den se ut:
App Redis
|---- GET foo ---->|
|<------ 1 --------|
| |
| thinking... |
| |
|--- SET foo 2 --->|
|<----- OK --------|
Låt oss nu se vad som händer när två appklienter försöker göra detta:
App 1 Redis App 2
|---- GET foo ---->| |
|<------ 1 --------|<--- GET foo -----|
| |------- 1 ------->|
| thinking... | |
| | thinking...|
|--- SET foo 2 --->| |
|<----- OK --------|<--- SET foo 2 ---|
| |------ OK ------->|
Här kan du omedelbart se vad som hände utan låsning, trots att servern (för det mesta) är enkeltrådad - istället för 3, foo s värde är 2. När du lägger till fler trådar/klienter/appar kan saker gå glatt och fruktansvärt fel när flera skribenter försöker ändra data utan koordination (t.ex. låsning).
Optimistisk låsning är bara ett av sätten att göra det, som Redis erbjuder inbyggt via WATCH mekanism. Ibland är dock optimism - trots sin lättsamma och glada natur - inte den rätta lösningen så du måste implementera bättre/avancerade/andra mekanismer för att förhindra tävlingsförhållanden. Sådana lås skulle utan tvekan kunna implementeras även utanför Redis, men om du redan använder det är det vettigt att hantera dina lås i det också.