Se Redis è a filettatura singola, allora perché è necessario un meccanismo di blocco.
Redis è effettivamente (principalmente) a thread singolo, ma è necessario il blocco quando più client tentano di fare cose diverse in prossimità temporale adiacente. Il blocco discusso in RiA riguarda esattamente questo:garantire che solo un client/thread esegua un'attività specifica o assicurarsi che gli aggiornamenti non vadano storti.
Ecco un esempio del motivo per cui avresti bisogno del blocco nonostante il thread singolo di Redis:supponi di avere un valore in Redis, ad esempio un numero memorizzato sotto una chiave denominata foo . Il codice della tua app legge quel numero (GET foo ), fa qualcosa (ad esempio aggiunge 1) e lo riscrive (SET ). Quando esegui il tuo codice in un singolo thread, ecco come apparirà:
App Redis
|---- GET foo ---->|
|<------ 1 --------|
| |
| thinking... |
| |
|--- SET foo 2 --->|
|<----- OK --------|
Ora vediamo cosa succede quando due client di app provano a farlo:
App 1 Redis App 2
|---- GET foo ---->| |
|<------ 1 --------|<--- GET foo -----|
| |------- 1 ------->|
| thinking... | |
| | thinking...|
|--- SET foo 2 --->| |
|<----- OK --------|<--- SET foo 2 ---|
| |------ OK ------->|
Qui puoi vedere immediatamente cosa è successo senza bloccare, nonostante il server sia (per lo più) a thread singolo - invece di 3, foo il valore di è 2. Man mano che aggiungi più thread/client/app, le cose possono andare allegramente e terribilmente storte quando più autori tentano di modificare i dati senza coordinamento (es. blocco).
Il blocco ottimistico è solo uno dei modi per farlo, che Redis offre integrato tramite WATCH meccanismo. A volte, tuttavia, l'ottimismo, nonostante la sua natura accomodante e felice, non è la soluzione giusta, quindi dovrai implementare meccanismi migliori/avanzati/diversi per prevenire le condizioni di gara. Tali blocchi potrebbero, probabilmente, essere implementati anche al di fuori di Redis, ma se lo stai già utilizzando, ha senso gestire anche i tuoi blocchi in esso.
