Redis
 sql >> Base de données >  >> NoSQL >> Redis

Redis :condition de course et thread unique

Si Redis est à thread unique, alors pourquoi avoir besoin d'un mécanisme de verrouillage.

Redis est en effet (principalement) à un seul thread, mais le verrouillage est nécessaire lorsque plusieurs clients tentent de faire des choses différentes à proximité temporelle adjacente. Le verrouillage discuté dans RiA concerne exactement cela - s'assurer qu'un seul client/thread effectue une tâche spécifique, ou s'assurer que les mises à jour ne tournent pas mal.

Voici un exemple de la raison pour laquelle vous auriez besoin d'un verrouillage malgré le thread unique de Redis :supposons que vous ayez une valeur dans Redis, un nombre par exemple stocké sous une clé nommée foo . Le code de votre application lit ce numéro (GET foo ), fait quelque chose (c'est-à-dire ajoute 1) et l'écrit (SET ). Lorsque vous exécutez votre code dans un seul thread, voici à quoi il ressemblerait :

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

Voyons maintenant ce qui se passe lorsque deux clients d'application essaient de faire ceci :

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

Ici, vous pouvez immédiatement voir ce qui s'est passé sans se verrouiller, bien que le serveur soit (principalement) à thread unique - au lieu de 3, foo La valeur de est 2. Au fur et à mesure que vous ajoutez plus de threads/clients/applications, les choses peuvent aller joyeusement et terriblement mal lorsque plusieurs rédacteurs tentent de modifier les données sans coordination (c'est-à-dire en les verrouillant).

Le verrouillage optimiste n'est qu'un des moyens d'y parvenir, que Redis propose en mode intégré via WATCH mécanisme. Parfois, cependant, l'optimisme - malgré sa nature facile à vivre et heureuse - n'est pas la bonne solution, vous devrez donc mettre en œuvre des mécanismes meilleurs/avancés/différents pour éviter les conditions de concurrence. De tels verrous pourraient sans doute être implémentés même en dehors de Redis, mais si vous l'utilisez déjà, il est logique d'y gérer également vos verrous.