Merci~ En fait, vous avez mal compris~ Je ne sais pas où vous avez vu cette information...
En fait... résoudre des problèmes de concurrence... n'est pas qu'un simple verrouillage de base de données... c'est nécessaire Cela se réalise grâce à une série de mise en cache, de détournement, de filtrage, etc. ~
Et l'idempotence n'est qu'une convention, il est convenu que dans la même opération, un seul des utilisateurs prendra effet. lorsqu'un utilisateur passe une commande sauvage, une seule prendra effet dans la pratique... La solution est très simple ~ divisée en deux couches... le point de contrôle du front-end ne peut plus être cliqué... le back-end identifie de manière unique la requête ~ puis l'enregistre dans le cache ~ une seule prendra réellement effet après cela ~

J'ai l'impression que les questions que vous avez posées ces dernières fois ressemblent davantage à ce qui est discuté dans les manuels scolaires, c'est loin d'être le cas. Il est recommandé de prêter attention à certains articles sur la technologie, par exemple. Principe de vente flash écrit par Taobao Alibaba Cloud a récemment publié L'architecture du système d'enveloppe rouge sous haute concurrence et d'autres informations pratiques résumées dans la production réelle ~

L'idempotence est une promesse (plutôt qu'une implémentation) faite par l'interface du système avec le monde extérieur. Elle promet que tant que l'interface est appelée avec succès, plusieurs appels externes auront le même impact sur le système. car l'idempotent considérera l'échec de l'appel externe comme normal, et il y aura certainement une nouvelle tentative après l'échec.

En ce qui concerne la prévention de la fragmentation des commandes que vous avez mentionnée, tout ce que je sais, c'est que cela repose sur des transactions. Je ne sais pas ce qu'ils utilisent dans des environnements à haute concurrence comme Alipay.

L'utilisation de jetons peut non seulement empêcher le CSRF, mais également empêcher la relecture au niveau de l'interface utilisateur.

Un exemple simple pour comprendre l'idempotence

public class Main {
    private int i = 0;
    
    //这个方法不具有幂等性，每调用一次，它就会改变Main的状态(即改变了i)
    public void idempotent() {
        i++;
    }
    
    //幂等性，无论这个方法调用多少次，它都不会改变Main类的状态。
    public void simple() {
        System.out.println(i);
    }
}

Je comprends que l'impression des commandes nécessite l'idempotence, qui est un état dans lequel les données ne peuvent pas être imprimées lors de l'impression des commandes. Peu importe le nombre de fois où la même commande est imprimée, cela n'affectera pas l'impression des autres commandes. Ceci est facile à contrôler. Ne modifiez pas les données de la base de données lors de l'impression de la commande. Récupérez les données côté application et traitez-les, afin qu'elles ne provoquent pas de fragmentation côté base de données.

L'égalité fait référence aux appels au système d'entreprise. Si plusieurs appels se produisent, il n'y aura aucun impact sur le système d'entreprise.
Cette exigence est très importante dans les systèmes distribués, car dans les systèmes distribués, la base de données elle-même ne peut pas effectuer le contrôle des transactions. Certaines files d'attente de messages et appels asynchrones seront utilisés pour effectuer des appels à distance lorsque l'état n'est pas clair. il tentera d'appeler à nouveau le service distant. Si le service n'a pas de garantie d'égalité, le mécanisme de nouvelle tentative ne peut pas être utilisé.

Le scénario de création d'une commande n'est pas équitable. Si elle est appelée plusieurs fois, plusieurs commandes apparaîtront. L'approche habituelle consiste à interroger sur la base des informations transmises avant de créer une commande. Si elle a déjà été exécutée, renvoyez directement les informations d'appel réussi pour éviter les commandes en double.

L'impuissance peut être comprise comme la requête GET en HTTP (ne dites pas que parfois le contenu est différent lorsque vous visitez la même URL), et la requête POST est non idempotente. Donc la plupart du temps, utiliser GET, c’est bien ! Ne pensez pas que POST est sûr car il masque les données corporelles.

L'impuissance résout le problème selon lequel si des raisons de réseau telles qu'un délai d'attente se produisent dans un système distribué, le client ne sait pas si le serveur s'est exécuté avec succès ou a échoué. À ce stade, le client doit réessayer. Si l'interface n'est pas idempotente. peut donner des résultats étonnamment différents.

Pour faire simple, si une interface est idempotente, l'effet sera le même si vous l'appelez une ou plusieurs fois. Par exemple

MISE À JOUR de la table SET NAME="LILEI" WHERE UID='1'

UPDATE table SET NAME="LILEI" WHERE UID='1'