【Description du problème】
Lorsque les utilisateurs utilisent l’APP, la page est très bloquée et ils cliqueront aléatoirement, car l’interface ne fait pas de soumissions répétées, il y aura plusieurs requêtes identiques dans la couche de service, un thread ne s’insère pas complet, et l’autre thread vérifie, vide. Alors j’en ai aussi inséré un. Au départ, tout le monde en avait un, mais un vendeur en avait trois, ce qui entraînait des erreurs de logique métier. Pour le traitement des soumissions malveillantes, cela peut se faire en front-end, et il peut aussi y avoir des solutions matures en back-end.
【Solution】1. Utiliser des contraintes d’unicité pour résoudre le problème d’idempotence des transactions, définir des contraintes d’unicité, et en cas de commits répétés, des exceptions aux contraintes d’unicité seront lancées au niveau de la base de données, et la logique métier ne sera pas détruite. Les contraintes d’unicité sur la composition de plusieurs champs sont également acceptables.
La connexion hyperlientérée est visible.
Ce qui précède vise à créer des paramètres anti-duplication au niveau de la base de données.
2. Réaliser les réglages anti-duplication au niveau du code. On dit souvent que la contrainte d’unicité de la base de données affectera l’efficacité de l’insertion des données, car chaque insertion nécessite un jugement au niveau de la base de données. Par conséquent, à en juger par le niveau du code, la pratique courante au niveau du code est de sélectionner d’abord puis d’insérer, mais en cas de forte concurrence de la concurrence, il y aura toujours des commits répétés. Vous pouvez ajouter synchronisation au code logique, de sorte que dans les scénarios de forte concurrence, sélectionnez d’abord puis insérez effet. Mais l’efficacité n’est pas élevée, et le parallèle devient sérieux. Un mécanisme de verrouillage DCL peut être utilisé. (Avez-vous constaté que la méthode de création d’un seul objet en mode de copie est très similaire : d’abord juger si l’objet existe, s’il n’existe pas, le créer, sinon ne pas le créer), le mécanisme naturel de verrouillage DCL est plus efficace.
#分布式锁
Les verrous distribués peuvent également être utilisés pour résoudre le problème, couramment utilisés par Redis et Zookeeper. Cette section explique comment implémenter des verrous distribués en utilisant Redis.
Il existe une opération de commande setNx dans Redis, si elle n’existe pas, c’est une valeur fixe, et 1 est retourné. Si elle existe, elle ne se fixe pas et retourne 0.
En utilisant la fonction de threading unique de Redis, la scène à forte concurrence est transformée en série via la file d’attente de messages.
Cependant, il existe des pièges dans les serrures distribuées, il faut donc faire attention.
La connexion hyperlientérée est visible.
3. Mécanisme MVCC ?
3.1 Qu’est-ce que le mécanisme MVCC ?
MVCC est un mécanisme de contrôle de concurrence multi-versions.
3.2 Quels problèmes peuvent être résolus ?
Le mécanisme de verrouillage peut contrôler les opérations simultanées, mais sa surcharge système est importante, et le MVCC peut remplacer les verrous au niveau des rangées dans la plupart des cas, ce qui peut réduire sa surcharge système et améliorer les performances.
La connexion hyperlientérée est visible.
4. Il existe aussi un problème d’idempotence dans les messages
Par exemple, comment éviter la consommation répétée de messages ?
Dans le middleware de message dans MQ, ces éléments doivent être compris et compris.
|
Publié sur 04/12/2018 13:29:37
|
|
|
Propriétaire