php - 高并发下悲观锁与乐观锁的选择问题

Question

说说我的看法，不对的地方请指正。

乐观锁的实现原理是cas操作，java中轻量级锁也是基于cas实现的。

悲观锁最大的问题就是阻塞问题。

在深入理解java虚拟机中提到，轻量级锁一般情况下是优于重量级锁（互斥锁）的；如果在高并发锁竞争比较激烈的情况下轻量级锁会由于长时间自旋消耗cpu 从而使得轻量级锁的性能比传统的重量级锁更慢。那么乐观锁中也有自旋和cas，所以高并发下乐观锁好像不是一种好的解决方案。

但是有些博文中提到 高并发下使用乐观锁更合适
比如这篇文章中就提到高并发数据库访问使用乐观锁
http://blog.csdn.net/amqvje/a...

问题1，高并发下如何选择？

问题2 乐观锁有什么缺点？ 为什不都使用乐观锁。高并发下都是使用乐观锁，如果并发量不高，使用乐观锁感觉更不是问题

Answer 1

En termes simples, dans des circonstances normales, le verrouillage optimiste convient aux opérations qui ne font que lire et non écrire, et le verrouillage pessimiste convient aux opérations mixtes de lecture et d'écriture. Si l'opération d'écriture est très simple et courte, comme par exemple pour augmenter le nombre de visiteurs, vous pouvez également utiliser le verrouillage optimiste, ou lorsqu'il n'est pas nécessaire de s'assurer que les données lues sont les plus récentes. Utiliser le verrouillage optimiste est en effet un meilleur choix dans 80 % des cas.

CAS s'appuie sur la prise en charge des instructions matérielles du processeur pour implémenter les opérations au niveau atomique. Il est donc généralement plus rapide dans des conditions de concurrence élevée. Cependant, cette vitesse n'est pas sans inconvénients. L'inconvénient est qu'en cas de lecture et d'écriture, le cache du processeur échoue. Le taux peut augmenter, sauf si votre processeur est monocœur (plateforme non Intel intégrée).

En bref, pour améliorer les performances de haute concurrence, nous avons toujours besoin de données mesurées réelles pour expliquer le problème. Ce que j'ai mentionné ci-dessus ne sont que des théories. J'espère que ça aide.

Answer 2

Qu'il s'agisse d'un verrouillage pessimiste ou d'un verrouillage optimiste, il s'agit en fait d'une idée de contrôle de concurrence, et il ne se limite pas à la base de données. Le choix spécifique du verrouillage optimiste et du verrouillage pessimiste est basé sur le scénario commercial.
Verrouillage pessimiste : 
Généralement, le verrou pessimiste que nous utilisons consiste à ajouter un verrou exclusif au niveau de la base de données. Si le verrouillage réussit, les données peuvent être modifiées et la transaction est soumise avec succès. échoue, cela signifie que les données sont en cours de modification. Si vous utilisez innodb de mysql, veillez à désactiver l'attribut mysql auto-commit, car mysql utilise le mode autocommit par défaut, c'est-à-dire que lorsque vous effectuez une opération de mise à jour, MySQL soumettra immédiatement le résultat et y fera également attention. au niveau de verrouillage, par défaut innodb utilise des verrous au niveau de la ligne, mais les verrous au niveau de la ligne sont basés sur des index. Si votre SQL n'utilise pas d'index, alors mysql utilisera des verrous au niveau de la table pour verrouiller la table. set autocommit=0Avantages et inconvénients :
Le verrouillage pessimiste est une stratégie conservatrice consistant à « obtenir d'abord le verrou, puis l'accès », qui offre une garantie pour la sécurité du traitement des données. Cependant, en termes d'efficacité, le mécanisme de verrouillage entraînera une surcharge supplémentaire pour la base de données et augmentera le risque de blocage. De plus, puisqu'il n'y aura pas de conflits dans le traitement des transactions en lecture seule, il n'est pas nécessaire d'utiliser des verrous, ce qui ne fera qu'augmenter la charge du système. Cela réduit également le parallélisme. Si une transaction verrouille une certaine ligne de données, les autres transactions doivent attendre que la transaction soit traitée avant de traiter cette ligne de données.

Verrouillage optimiste : 

Le verrouillage optimiste suppose en fait que les données ne provoqueront pas de conflits dans des circonstances normales. Ainsi, lorsque les données sont soumises pour mise à jour, le conflit de données sera officiellement détecté. Si un conflit est détecté, l'utilisateur sera renvoyé. Informations sur les erreurs et laissez l'utilisateur décider quoi faire.
Généralement, il peut être écrit directement dans la couche logique du code. Par rapport au verrouillage pessimiste, lors du traitement de la base de données, le verrouillage optimiste n'utilise pas le mécanisme de verrouillage fourni par la base de données. Il est généralement implémenté en utilisant un numéro de version ou un horodatage. Lorsque vous utilisez un numéro de version, vous pouvez spécifier un numéro de version lors de l'initialisation des données, et chaque opération de mise à jour sur les données ajoutera 1 au numéro de version. Et déterminez si le numéro de version actuel est le dernier numéro de version des données. Tel que :

1.查询出商品信息
select (status,version) from t_goods where id=#{id}
2.根据商品信息生成订单
3.修改商品status为2
update t_goods 
set status=2,version=version+1
where id=#{id} and version=#{version};

Avantages et inconvénients : 

Le verrouillage optimiste estime que la probabilité de concurrence des données est très faible. Par conséquent, procédez aussi directement que possible et ne verrouillez pas jusqu'à la soumission, afin qu'aucun verrouillage ni blocage ne se produise. Mais si vous faites cela simplement, vous pouvez toujours rencontrer des résultats inattendus. Par exemple, si deux transactions lisent une certaine ligne de la base de données puis la réécrivent dans la base de données après modification, vous rencontrerez des problèmes.
L'échec du verrouillage optimiste est un événement peu probable et nécessite la coopération de plusieurs conditions pour se produire. Tel que :

• L'application adopte sa propre stratégie pour gérer l'ID de la clé primaire. Par exemple, il est courant de prendre la valeur maximale du champ ID actuel + 1 comme nouvel ID.

• La valeur par défaut du champ du numéro de version est 0.

• L'utilisateur A lit un certain enregistrement et se prépare à le modifier. Cet enregistrement se trouve être l'enregistrement avec le plus grand ID et n'a pas été modifié auparavant. La version est la valeur par défaut 0.

• Une fois la lecture terminée par l'utilisateur A, l'utilisateur B a supprimé l'enregistrement. Après cela, l'utilisateur C a inséré un nouvel enregistrement.

• À l'heure actuelle, par erreur, l'ID de l'enregistrement nouvellement inséré est cohérent avec l'ID de l'enregistrement lu par l'utilisateur A, et les deux numéros de version ont la valeur par défaut 0.

• Une fois l'utilisateur C terminé l'opération, l'utilisateur A modifie l'enregistrement terminé et l'enregistre. Étant donné que l’ID et la version peuvent correspondre, l’utilisateur A enregistre avec succès. Cependant, l'enregistrement inséré par l'utilisateur C a été écrasé.
  La raison fondamentale de l'échec du verrouillage optimiste à l'heure actuelle est que la stratégie de gestion des identifiants de clé primaire utilisée par l'application est dans une très faible mesure incompatible avec le verrouillage optimiste.

Answer 3

Avant de commencer à travailler, j'avais la même idée que l'interrogateur. Dans le travail réel, il n'y a en fait pas beaucoup de différence entre les deux. La partie la plus chronophage du système en cas de concurrence élevée est toujours la connexion réseau, la requête de base de données et. la veille active des threads entraîne une surcharge.

Answer 4

La question clé est la suivante : les faits sont-ils pessimistes ou optimistes ?

Si votre concurrence en matière de ressources est féroce et ne peut pas être partagée, le verrouillage optimiste va tout simplement vaincre l'espoir d'un grand nombre de requêtes.

S'il n'y a pas de concurrence pour vos ressources (cela n'est pas nécessairement lié au niveau de concurrence, mais a un plus grand impact sur l'entreprise), alors un verrouillage pessimiste signifie un verrouillage inutile. Si la ressource était initialement partageable (par exemple, la ressource prend en charge plusieurs parties en lecture seule), alors le verrouillage pessimiste signifie la perte de la durée d'utilisation d'origine.

Dans la compréhension approfondie de la machine virtuelle Java, il est mentionné que les verrous légers sont généralement meilleurs que les verrous lourds (verrous mutex) si la concurrence pour les verrous à haute concurrence est féroce, les verrous légers seront verrouillés pendant longtemps ; Le temps de rotation consomme du processeur, ce qui rend les performances des verrous légers plus lentes que celles des verrous lourds traditionnels. Ensuite, le verrouillage optimiste inclut également spin et cas, donc le verrouillage pessimiste sous forte concurrence ne semble pas être une bonne solution.

Je ne connais pas grand-chose à JVM. Mais que signifie « Spin et cas existent aussi en verrouillage optimiste » ? cas est une méthode d'implémentation du spin lock. Pourquoi devrait-il être mis en parallèle ? Que signifie « aussi » ? Le verrouillage pessimiste est une opération de blocage, il n'y a pas de rotation et il ne consomme pas continuellement le processeur.