La semaine dernière, j'ai remarqué un bug caché dans notre ancien code : lorsque les utilisateurs essayaient de mettre à jour la même ressource en même temps, techniquement parlant, quelques millisecondes avant ou après, ils pouvaient tous fonctionner sans erreur ni exception. C'était une merde !

La concurrence était le cas

Lorsque plusieurs utilisateurs envoyaient des requêtes l'une après l'autre, la méthode asynchrone qui gérait les appels et travaillait sur la ressource mettait à jour plus d'une fois la même ressource alors qu'un processus avait déjà démarré auparavant (ici le processus est la première demande de l'utilisateur appelant) et non terminé au moment de la demande de l'utilisateur suivant.

En effet, il aurait fallu réagir comme une transaction .

Avez-vous entendu parler de Redis ?

Redis est un magasin de structure de données en mémoire open source (sous licence BSD) utilisé comme base de données, cache, courtier de messages et moteur de diffusion. Il prend en charge les types de données primaires, même les objets, etc. J'ai utilisé son stockage de clés pour résoudre le problème de concurrence.

Comment résoudre le dilemme de la concurrence avec Redis ?

Que se passe-t-il si la ressource a quelque chose d'identique, comme une clé primaire (id) qui peut la différencier ? C'était un moment où la lumière a commencé à clignoter dans mon cerveau.

La solution est assez simple :

J'ai ajouté des clés primaires de source partagée à un tableau qui a ensuite été stocké dans Redis. Lorsqu'un processus s'est terminé sur une ressource, la clé primaire a été supprimée du tableau et stockée à nouveau dans Redis. Si un utilisateur essayait de mettre à jour la ressource qui était déjà en cours de traitement par un autre utilisateur, le code vérifierait les éléments du tableau : s'il existe une clé primaire identique à la demande à venir, cela générerait une erreur 409 (conflit).

Qu'en est-il du verrouillage ?

Le verrouillage est une procédure orientée CPU qui empêche de travailler sur une ressource partagée. Si le numéro d'utilisateur sur la même ressource est inférieur à 20, le temps d'attente devrait être acceptable. Mais qu'en est-il de 1000 ?

Bien sûr, vous ne voulez pas que vos utilisateurs attendent des heures. Ici, Redis pourrait vous donner un coup de main.

Conclusion

Ainsi, l'utilisation de la technologie en mémoire, appelée Redis, est un moyen plus efficace que le verrouillage des ressources avec Semaphore ou Mutex. En tant que développeur et décideur, vous devez en choisir un qui correspond à votre dilemme .

J'espère que cela aidera les lecteurs!