I. Aperçu
Lors du développement du système de commande, nous rencontrons souvent des problèmes de paiement. Une fois que l'utilisateur a acheté les marchandises, le paiement est déduit avec succès, mais le réseau est anormal lorsque le résultat est renvoyé. À ce moment-là, l'argent a été déduit. Si l'utilisateur clique " Appuyez à nouveau sur le bouton, le deuxième processus sera effectué. La déduction a réussi et le résultat renvoyé a été réussi. L'utilisateur a vérifié le solde et a constaté que plus d'argent avait été déduit, et l'enregistrement de la transaction est également devenu deux.
Dans l'ancien système à application unique, il suffisait de mettre les opérations de données dans les transactions et d'annuler immédiatement lorsqu'une erreur se produisait. Cependant, des interruptions de réseau ou des problèmes anormaux peuvent également survenir lors de la réponse au client. S'il est garanti que les données sont cohérentes tout au long du cycle de vie de la commande, de la création au paiement réussi d'une commande et ne changeront pas en raison d'exceptions. Ce mécanisme nécessite le recours à l'idempotence.
2. Qu'est-ce que l'idempotence ?
L'idempotence est un concept mathématique et informatique courant en algèbre abstraite.
Une fonction idempotente, ou méthode idempotente, est une fonction qui peut être exécutée de manière répétée avec les mêmes paramètres et obtenir le même résultat. Ces fonctions n'affecteront pas l'état du système et il n'y a pas lieu de s'inquiéter des modifications du système provoquées par des exécutions répétées.
Idempotence : toute exécution multiple a le même impact sur la ressource elle-même qu'une seule exécution
L'idempotence de l'interface signifie en fait que l'interface peut être appelée à plusieurs reprises. Lorsque l'appelant appelle plusieurs fois, le résultat final de l'interface est le même. Certaines interfaces peuvent être naturellement idempotentes, comme l'interface de requête, appelant une fois et appelant plusieurs fois. fois, les résultats obtenus par le système sont les mêmes. Les résultats de la requête ne changeront pas en fonction du nombre d'appels.
Les méthodes d'insertion (INSERT) et de modification (UPDATE) ne sont pas idempotentes et doivent être traitées dans les scénarios requis via des mécanismes pour garantir que les exécutions multiples n'ont pas d'effets secondaires.
Si la suppression est exécutée une ou plusieurs fois, le résultat sera vide (c'est-à-dire que le résultat est cohérent) et n'aura aucun effet secondaire. Par conséquent, la suppression basée sur l'ID de clé primaire peut être considérée comme (pseudo) idempotente. Si la suppression est basée sur une clé non primaire, elle sera exécutée plusieurs fois. Il n'y a pas d'effets secondaires (les données sont supprimées), et elle peut également être considérée comme (pseudo) idempotente.
3. L’idempotence nécessite une attention particulière à plusieurs points clés
- L'idempotence ne signifie pas seulement qu'une (ou plusieurs) requêtes n'ont aucun effet secondaire sur les ressources (comme l'interrogation des opérations de base de données, il n'y a pas d'ajouts, de suppressions ou de modifications, donc il n'y a aucun impact sur la base de données)
- L'idempotence inclut également des effets secondaires sur la ressource lors de la première requête, mais les requêtes ultérieures n'auront pas d'effets secondaires sur la ressource.
- L'idempotence se concentre sur la question de savoir si les demandes multiples ultérieures ont des effets secondaires sur les ressources, mais ne se concentre pas sur les résultats.
- Les problèmes tels que le délai d'attente du réseau ne relèvent pas du champ d'application des discussions idempotentes.
L'idempotence est une promesse (plutôt qu'une implémentation) faite par le service système au 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. Un service déclaré idempotent considérera l'échec des appels externes comme normal, et il y aura certainement des tentatives après un échec.
4. A quoi sert l’idempotence ?
Dans le développement commercial, nous rencontrons souvent des soumissions répétées, que ce soit en raison de problèmes de réseau qui ne peuvent pas recevoir les résultats de la demande et relancer la demande, ou que la nervosité des opérations frontales provoque des soumissions répétées. Dans le système commercial et le système de paiement, les problèmes causés par des soumissions répétées sont particulièrement évidents, tels que :
- Si l'utilisateur clique plusieurs fois sur l'APP pour soumettre une commande, une seule commande doit être générée en arrière-plan ;
- Initiez une demande de paiement à Alipay. En raison de problèmes de réseau ou de bugs du système, Alipay ne doit déduire l'argent qu'une seule fois. Évidemment, les services déclarés idempotents croient que les appelants externes effectueront plusieurs appels. Afin d'éviter que plusieurs appels externes ne provoquent de multiples modifications de l'état des données du système, le service est conçu pour être idempotent.
- Les demandes répétées de commandes sortantes génèrent plusieurs informations sur les commandes sortantes.
5. Moyens courants utilisés pour garantir l’idempotence
5.1 Solution MVCC
Contrôle de concurrence multi-versions, cette stratégie utilise principalement la mise à jour avec condition (mise à jour avec condition pour empêcher) pour garantir que plusieurs appels de requêtes externes ont un impact cohérent sur le système. Dans le processus de conception du système, le verrouillage optimiste doit être utilisé de manière rationnelle et d'autres conditions telles que la version ou updateTime (horodatage) doivent être utilisées pour déterminer les conditions du verrouillage optimiste. Cela garantit que l'opération de mise à jour n'aura pas trop d'impact même dans situations concurrentes. Par exemple
select * from tablename where condition=#condition# //取出要跟新的对象，带有版本versoin
update tableName set name=#name#,version=version+1 where version=#version#
Utilisez la version pendant le processus de mise à jour pour empêcher d'autres opérations de mettre à jour simultanément l'objet, ce qui entraînerait une perte de mises à jour. Afin d'éviter les échecs, un certain mécanisme de nouvelle tentative est généralement requis.
5.2 Tableau de déduplication
Lors de l'insertion de données, insérez la table de déduplication et utilisez la fonction d'index unique de la base de données pour garantir une logique unique.
Cette méthode convient aux scénarios dans lesquels il existe une cible unique dans l'entreprise. Par exemple, dans le scénario de paiement ci-dessus, si une commande ne sera payée qu'une seule fois, l'ID de la commande peut être utilisé comme identifiant unique. À ce stade, nous pouvons créer une table de déduplication et utiliser l'identifiant unique comme index unique. Lorsque nous l'implémenterons, nous créerons le document de paiement et l'écrirons dans la table de déduplication en une seule transaction. S'il est créé à plusieurs reprises, la base de données will Si une exception de contrainte unique est levée, l'opération sera annulée.
5.3 Tableau de déduplication
sélectionné pour la mise à jour, l'enregistrement correspondant à la commande est verrouillé pendant tout le processus d'exécution. Remarque : utilisez-le le moins possible lorsque la lecture de la base de données est supérieure à l'écriture.
5.4 sélectionner + insérer
Pour les systèmes d'arrière-plan à faible concurrence ou certains JOB de tâches, afin de prendre en charge l'idempotence et l'exécution répétée, la méthode de traitement simple consiste à interroger d'abord certaines données clés pour déterminer si elles ont été exécutées avant de poursuivre le traitement métier. Remarque : N'utilisez pas cette méthode pour les processus principaux à haute concurrence.
5.5 Machine à états idempotente
Lors de la conception d'activités liées à un document ou à une tâche, des machines à états seront certainement impliquées. Autrement dit, il y a un état sur le document commercial, et l'état changera dans différentes circonstances. Généralement, il existe une machine à états finis. cette fois, si la machine à états est déjà dans l'état suivant et qu'un changement vers l'état précédent se produit à ce moment-là, le changement ne peut pas être effectué en théorie. Dans ce cas, l'idempotence de la machine à états finie est garantie.
Cette méthode convient lorsqu'il y a un flux de machine d'état, comme la création et le paiement d'une commande. Le paiement de la commande doit être antérieur. À ce stade, nous pouvons utiliser le type int lors de la conception du champ d'état, et passer le type de valeur La taille est idempotente, par exemple, la création de commande est de 1 000 et le succès du paiement est de 1. Le paiement a échoué pour 999.
5.6 Mécanisme de jeton pour empêcher la soumission répétée de pages
Exigences commerciales : les données de la page ne peuvent être cliquées et soumises qu'une seule fois.
Cause : les données sont soumises à plusieurs reprises en raison de clics répétés, de renvois réseau ou de renvois nginx.
Solution :
- Environnement de cluster : utilisez un jeton plus redis (redis est monothread, le traitement doit être mis en file d'attente)
- Environnement JVM unique : utilisez un jeton plus redis ou un jeton plus la mémoire jvm
Flux de traitement :
- Avant de soumettre des données, vous devez demander un jeton auprès du service. Le jeton est placé dans la mémoire redis ou jvm et le jeton est valide pour
- Après la soumission, le jeton est vérifié en arrière-plan, le jeton est supprimé et un nouveau jeton est généré et renvoyé.
- Caractéristiques du jeton : pour postuler, il n'est valable qu'une seule fois et le flux actuel peut être limité
5.7 Comment garantir l'idempotence des API qui fournissent des interfaces externes
Par exemple, l'interface de paiement fournie par WeChat doit être connectée au commerçant pour soumettre une demande de paiement avec : la source source et le numéro de série séq. source+seq crée un index unique dans la base de données pour éviter les paiements multiples (une seule demande peut être traitée pendant la simultanéité)
"Résumé : " L'idempotence devrait être un gène des programmeurs qualifiés. Lors de la conception d'un système, c'est la considération primordiale, en particulier dans les systèmes tels qu'Alipay, les banques, les sociétés financières sur Internet, etc. qui impliquent tous de l'argent. Il doit être efficace. , les données doivent également être exactes, afin que des problèmes tels que des déductions excessives et des paiements en trop ne puissent pas survenir. Cela sera difficile à gérer et l'expérience utilisateur ne sera pas bonne.
5.7 ID unique au monde
Si un identifiant global unique est utilisé, un identifiant global est généré en fonction de l'opération et du contenu de l'entreprise. Avant d'exécuter l'opération, il est jugé si l'opération a été exécutée en fonction de l'existence ou non de l'identifiant global unique. S'il n'existe pas, stockez l'ID global dans le système de stockage, tel que la base de données, Redis, etc. S'il existe, cela signifie que la méthode a été exécutée.
D'un point de vue technique, l'utilisation d'ID globaux pour être idempotent peut exister en tant que microservice qui constitue la base d'une entreprise. De tels services sont utilisés dans de nombreux microservices. Si de telles fonctions sont remplies dans chaque microservice, il y aura une duplication de la charge de travail. De plus, de nombreux problèmes doivent être pris en compte pour créer un service idempotent hautement fiable. Par exemple, même si une machine écrit d'abord l'ID global sur le stockage, elle se bloque après l'écriture. Cela nécessite l'introduction d'un mécanisme de délai d'attente pour l'ID global.
L’utilisation d’un identifiant unique au monde est une solution générale qui peut prendre en charge les opérations commerciales d’insertion, de mise à jour et de suppression. Cependant, cette solution semble belle mais est difficile à mettre en œuvre. La solution suivante convient à des scénarios spécifiques, mais est relativement simple à mettre en œuvre.
5.8 Verrouillage distribué
Lors de la saisie de la méthode, commencez par acquérir le verrou. Si le verrou est acquis, poursuivez le processus suivant. Si le verrou n'est pas acquis, attendez qu'il soit libéré jusqu'à ce qu'il soit acquis. Une fois l’exécution de la méthode terminée, le verrou est libéré. Bien entendu, le verrou doit avoir un délai d’attente pour éviter qu’il ne soit accidentellement libéré. Il est utilisé pour résoudre l'idempotence des systèmes distribués.Les solutions d'implémentation couramment utilisées sont des outils tels que redis et zookeeper.
6. Résumé
L'idempotence ajoute une logique métier supplémentaire pour contrôler l'idempotence, complique les fonctions métier, modifie les fonctions d'exécution parallèle en exécution en série et réduit l'efficacité de l'exécution.
Bien que l'idempotence complique les fonctions commerciales et réduit l'efficacité de l'exécution, il est nécessaire de garantir l'exactitude du système. En prenant l'exemple ci-dessus de mise à jour de X, sur un seul serveur, l'ajout d'un verrou à ce code et la définition de X sur volatile garantiront l'exactitude des données entrantes.
Dans un environnement distribué et où X est interrogé à partir de la base de données ou du fichier, l'exactitude des données ne peut pas être garantie par la méthode de verrouillage ci-dessus. À ce stade, des verrous distribués doivent être utilisés. Par conséquent, il est très nécessaire de garantir l’idempotence des méthodes ou des interfaces, car il ne peut y avoir aucun problème avec les données.