Pourquoi le thread unique Redis doit-il être verrouillé ?

Ma compréhension personnelle est que bien que Redis soit monothread, plusieurs clients peuvent y accéder en même temps, et chaque client aura un thread. Il existe une concurrence entre les accès clients.

Parce qu'il y a plusieurs clients simultanément, l'atomicité de l'opération doit être garantie. Par exemple, lorsqu'il s'agit de prélèvements par carte bancaire, l'obtention du solde, le jugement, le prélèvement et la réécriture doivent constituer une transaction, sinon des erreurs peuvent survenir.

Dans le cas d'un déploiement traditionnel sur une seule machine, les verrous liés à la concurrence Java, tels que ReentrantLcok ou synchronisé, peuvent être utilisés pour le contrôle d'exclusion mutuelle. Cependant, avec les besoins du développement commercial, le système de déploiement d'origine sur une seule machine a été progressivement déployé sur plusieurs machines et plusieurs JVM pour fournir des services simultanément, ce qui a rendu invalide la stratégie de verrouillage du contrôle de concurrence dans le déploiement d'origine sur une seule machine afin de résoudre. Ce problème, Un mécanisme d'exclusion mutuelle entre JVM est nécessaire pour contrôler l'accès aux ressources partagées. C'est le problème que les verrous distribués veulent résoudre. (Apprentissage recommandé : Tutoriel vidéo Redis)

Conditions de mise en œuvre des verrous distribués

1. Exclusivité mutuelle, identique à une application unique, C'est. nécessaire de s'assurer qu'un seul client détient la serrure à tout moment

2. Fiabilité, la stabilité du système doit être assurée, et une impasse ne peut pas se produire

3. Cohérence, la serrure doit être garanti Il ne peut être déverrouillé que par la personne qui l'a verrouillé, et le verrou de A ne peut pas être déverrouillé par l'utilisateur B

Différentes personnes implémentant des verrous distribués dans Redis peuvent avoir une logique d'implémentation différente.

Dans un environnement distribué, la question de la cohérence des données a toujours été un sujet important, mais elle est différente de la situation d'un processus unique. La plus grande différence entre les situations distribuées et celles sur une seule machine est qu'il ne s'agit pas d'un système multithread mais multiprocessus. Étant donné que les multithreads peuvent partager la mémoire tas, ils peuvent simplement utiliser la mémoire comme emplacement de stockage de marquage. Les processus peuvent même ne pas se trouver sur la même machine physique, la balise doit donc être stockée dans un endroit où tous les processus peuvent la voir.

Un scénario de vente flash courant est celui où plusieurs instances du service de commande sont déployées. Par exemple, s'il y a 4 articles en vente flash, le premier utilisateur achète 3 articles et le deuxième utilisateur achète 2 articles. Idéalement, le premier utilisateur peut acheter avec succès et le deuxième utilisateur sera informé que l'achat a échoué, et vice versa. . Ce qui peut réellement arriver, c'est que les deux utilisateurs obtiennent un inventaire de 4 et que le premier utilisateur en achète 3. Avant de mettre à jour l'inventaire, le deuxième utilisateur passe une commande de 2 articles et met à jour l'inventaire à 2, provoquant une erreur.

Les schémas de verrouillage courants sont les suivants :

Implémentation de verrous distribués basés sur une base de données

Implémentation de verrous distribués basés sur le cache, tels que redis

Implémentation de verrous distribués basés sur Zookeeper

Pour plus d'articles techniques liés à Redis, veuillez visiter la colonne Tutoriel de démarrage sur l'utilisation de la base de données Redis pour apprendre !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!