Apprentissage recommandé : Tutoriel vidéo Redis
Les verrous en Java incluent principalement les verrous synchronisés et les verrous dans le package JUC. Ces verrous sont destinés aux verrous sur une seule instance JVM et ne sont pas valides pour les environnements distribués. implémentation basée sur un verrouillage distribué ?
La mise en œuvre des verrous distribués courants est la suivante :
Verrouillage pessimiste (Verrouillage pessimiste), comme son nom l'indique, est un verrou très pessimiste, et il sera verrouillé à chaque fois que les données sont récupérées. De cette façon, les autres personnes souhaitant obtenir les données seront bloquées jusqu'à ce que le verrou pessimiste soit libéré. Les ressources partagées dans le verrou pessimiste ne sont utilisées que par un thread à la fois, et les autres threads sont bloqués après utilisation. transféré à d'autres threads Cependant, en termes d'efficacité, le traitement du mécanisme de verrouillage génère une surcharge supplémentaire et est sujet à des blocages.
Le contrôle de concurrence pessimiste est en fait une stratégie conservatrice consistant à "obtenir d'abord le verrou, puis l'accès", qui fournit une garantie pour la sécurité du traitement des données.
Par exemple, l'inventaire la déduction est obtenue grâce au verrouillage pessimiste. Le pseudo-code est le suivant :
// 对于库存记录进行行锁 SELECT *FROM sys_goods s WHERE s.Id='1' FOR UPDATE; //执行库存扣减 update sys_stock s set s.stockQty=s.stockQty-#{number} where s.goodId=1 and s.stockQty>0; //提交事务,自动释放悲观锁。
Le verrouillage optimiste est implémenté sur la base du mécanisme de numéro de version des données (version). Ajoutez un champ "version" à la table de la base de données. Lors de la lecture des données, ce numéro de version est lu lors du processus de mise à jour, s'ils sont cohérents, l'opération sera exécutée avec succès et le numéro de version sera. incrémenté. 1. Si les numéros de version sont incohérents, la mise à jour échouera.
Par rapport au verrouillage pessimiste, la mise en œuvre du verrouillage optimiste n'utilise pas le mécanisme de verrouillage de la base de données. Le principe du verrouillage optimiste est implémenté à l'aide du mécanisme CAS (Compare-and-Swap) signifie comparer et remplacer. .
Par exemple, le pseudo-code pour le verrouillage optimiste pour réaliser la déduction des stocks est le suivant :
// 查询库存记录,获取版本号 SELECT stockQty,version FROM sys_goods s WHERE s.Id='1' //执行库存扣减,防止出现超卖 update sys_stock s set s.stockQty=s.stockQty-#{number}, s.version=version+1 where s.goodId=1 and s.stockQty>0 and version=#{version};
À propos de l'implémentation du verrouillage distribué Redis, cela a été expliqué dans les articles précédents
Spring Boot implémente le principe du verrouillage distribué Redis
Spring Boot intègre Redisson pour implémenter le cas détaillé du verrouillage distribué
Zookper implémente le verrouillage distribué, principalement en utilisant le temporaire et le temporaire. somme des nœuds zookeeper Pour assurer l'ordre.
Lorsque le client 1 le demande, le client Zookeeper créera un nœud de verrouillage de nœud persistant. Si le client 1 souhaite acquérir le verrou, il créera un nœud temporaire /node_000000 sous le nœud de verrouillage. sous Verrous Un nœud enfant ordonné acquiert le verrou avec succès lorsqu'il s'agit du plus petit nœud.
Lorsque le client 2 tente d'acquérir le verrou, il vérifiera également les nœuds temporaires sous les verrous pour déterminer si son propre nœud/node_000001 est le plus petit. S'il n'est pas le plus petit, l'acquisition du verrou échoue et le client 2. le triera au premier plan. Le nœud node_000000 enregistre un événement de surveillance pour surveiller si node_000000 existe. Bien que la capture du verrou échoue, node_000001 entre dans l'état d'attente.
Lorsque l'activité du client de Zookeeper est terminée ou que le client échoue, le nœud temporaire sera supprimé et le verrou sera libéré. Si la tâche est terminée, le client 1 appellera également explicitement l'instruction de suppression de node_000000.
Par exemple, dans la figure ci-dessus, le client 1 est déconnecté et le nœud temporaire node_000000 a été supprimé. À ce stade, node_000001 se retrouve comme le plus petit nœud temporaire grâce à la surveillance de l'observateur, le verrou est donc acquis avec succès.
客户端1创建临时节点后,会与Zookeeper服务器维护一个Session,这个Session会依赖客户端 定时心跳来维持连接。由于网路异常原因,Zookeeper长时间收不到客户端1的心跳,就认为这个Session过期了,也会把这个临时节点删除,此时客户端2创建临时节点能够获取锁成功。当客户端网络恢复正常后,它仍然认为持有锁,此时就会造成锁冲突。
Zookeeper实现分布式锁,可以采用Curator实现分布式锁,关于SpringBoot如何集成Curator,大家可以参考如下文章:
Java Spring Boot 集成Zookeeper
@RequestMapping("/lockStock") public void lockStock() { zooKeeperUtil.lock("/Locks", 1000, TimeUnit.SECONDS, ()->{ //业务逻辑 }); }
小结:
关于分布式锁的实现的对比,详情请查看下图:
推荐学习:Redis视频教程
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!