Le verrou distribué de Redis est-il un verrou optimiste ?

Pour faire simple, Redis utilise le verrouillage optimiste, qui est plus simple à mettre en œuvre que le verrouillage pessimiste et offre de meilleures performances dans certains scénarios. En tant que moteur de mise en cache léger et rapide, Redis n'est pas une base de données relationnelle complète. Il n'est ni nécessaire ni abordable d'utiliser des verrous pessimistes.

Optimistic Lock, comme son nom l'indique, est très optimiste. Chaque fois que vous allez chercher les données, vous pensez que les autres ne les modifieront pas, alors vous. ne le verrouillera pas, mais lors de la mise à jour, vous pouvez vérifier si d'autres ont mis à jour ces données pendant la mise à jour. Vous pouvez utiliser des mécanismes tels que les numéros de version. Le verrouillage optimiste convient aux types d'applications à lectures multiples, ce qui peut améliorer le débit.

Stratégie de verrouillage optimiste : la version soumise doit être supérieure à la version actuelle de l'enregistrement avant que les mises à jour puissent être effectuées (apprentissage recommandé : Tutoriel vidéo Redis)

Redis uniquement fournit une prise en charge très limitée pour les transactions, il s'agit en fait davantage d'une tentative de contourner le problème.

Tout d'abord, Redis n'exécute pas immédiatement un ensemble d'opérations dans la même transaction, mais les met dans une file d'attente. Lorsque EXEC est exécuté, elles sont exécutées ensemble. L'exécution des transactions est globalement exclusive, c'est-à-dire qu'une seule transaction est exécutée en même temps et ne peut pas être interrompue par d'autres transactions intermédiaires. Redis utilise ce moyen le plus simple et le moins performant pour éviter les conditions de concurrence.

Deuxièmement, dans une transaction Redis, si une ou plusieurs opérations échouent, d'autres opérations réussiront toujours, ce qui signifie qu'il n'y a aucun mécanisme de restauration.

Cette méthode entraînera de nombreux problèmes sérieux. L'un d'eux est qu'il est impossible de lire d'abord une certaine valeur puis d'effectuer des opérations qui dépendent de cette valeur, car la mettre dans une transaction se fera au moment même. au même moment, le fait de ne pas le placer dans la même transaction entraînera des conditions de concurrence. La solution consiste à utiliser WATCH, qui surveillera une ou plusieurs variables. Si la valeur de la variable est modifiée par une autre transaction après avoir appelé WATCH et avant que la transaction ne soit validée, la transaction entière échouera. Ceci est similaire au CAS (Compare and Set) dans les systèmes d'exploitation. Je ne sais pas comment WATCH est implémenté spécifiquement, mais je suppose qu'il surveille le numéro de version de la variable spécifiée.

Même avec WATCH, les transactions Redis sont sévèrement limitées. Premièrement, il n'obtient pas de cohérence lors de la lecture des données, car WATCH ne fonctionne pas pour les opérations de lecture. Deuxièmement, il ne prend pas en charge la restauration. Troisièmement, lorsqu'il y a un grand nombre d'opérations d'écriture simultanées sur la même variable, les performances seront très mauvaises, car chaque fois qu'une transaction est soumise, les variables surveillées par WATCH ont été modifiées, ce qui a entraîné l'échec de la soumission de la transaction à plusieurs reprises. . Cependant, Redis est à l'origine un moteur de cache de type KV. Il doit gérer des scénarios de grandes quantités de lecture et de petites quantités d'écriture, et il n'y a aucune exigence de cohérence.

Pour plus d'articles techniques liés à Redis, veuillez visiter la colonne Introduction au didacticiel d'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!