L'impuissance signifie généralement que la méthode ne change pas le statut de l'entreprise, elle peut donc garantir que l'effet des appels répétés est le même que l'effet d'un seul appel.
En regardant votre description, vos tâches planifiées et traitements asynchrones sont susceptibles de modifier le statut de l'entreprise (comme l'insertion de données). Il est probable que votre méthode elle-même ne soit pas une méthode. puissance Attendez. Si tel est le cas, il n'y a fondamentalement aucune solution.
Je pense que l'idée derrière votre question pourrait être : dans un environnement distribué, comment garantir que lors de l'envoi de demandes répétées pour des tâches planifiées et un traitement asynchrone, la logique métier réelle est exécutée uniquement une fois ?
Si tel est le cas, vous pouvez utiliser un stockage centralisé (tel que redis) pour enregistrer l'enregistrement de la demande de l'appelant. Après avoir reçu la demande, le serveur utilise des opérations de requête atomique et de sauvegarde (telles que la commande
setnx de redis). , pour garantir qu'une seule demande sera enregistrée avec succès. Cela peut avoir pour effet de n'exécuter l'activité réelle qu'une seule fois.
Je n'ai aucune expérience dans ce domaine, mais l'approche de l'entreprise consiste à utiliser l'IP pour porter des jugements, et seule l'IP désignée peut exécuter cette tâche planifiée.
Ce qui suit est un fantasme personnel sans expérience pratique : Créez une application publique spécifiquement pour gérer les tâches planifiées, puis fournissez une interface de message pour que des applications spécifiques puissent l'appeler.
Rendre l'opération elle-même idempotente, comme changer l'opération +1 en = opération
Donnez à chaque opération un identifiant et enregistrez chaque exécution Avant l'exécution, vérifiez si l'opération avec cet identifiant a été exécutée auparavant
Vous pouvez envisager une file d'attente de messages avec un mécanisme d'accusé de réception, tel que RabbitMQ, etc., qui garantit non seulement qu'une tâche n'est assignée qu'à un seul travailleur, mais garantit également l'intégrité du succès de la tâche
Nous y parvenons grâce à la planification zk. Dans un environnement distribué, une tâche ne peut être exécutée que par une seule machine au maximum. ZK peut très bien réaliser cette fonction
Toutes les réponses jusqu'à présent sont fausses, y compris celle acceptée. La raison en est que les tâches planifiées ou les traitements asynchrones n’ont rien à voir avec l’idempotence.
Utilisez une file d'attente. Une fois que vous l'aurez prise, elle ne sera exécutée qu'une seule fois. Si l'exécution échoue, elle sera renvoyée dans la file d'attente et attendra la prochaine fois
L'impuissance signifie généralement que la méthode ne change pas le statut de l'entreprise, elle peut donc garantir que l'effet des appels répétés est le même que l'effet d'un seul appel.
En regardant votre description, vos tâches planifiées et traitements asynchrones sont susceptibles de modifier le statut de l'entreprise (comme l'insertion de données). Il est probable que votre méthode elle-même ne soit pas une méthode. puissance Attendez. Si tel est le cas, il n'y a fondamentalement aucune solution.
Je pense que l'idée derrière votre question pourrait être : dans un environnement distribué, comment garantir que lors de l'envoi de demandes répétées pour des tâches planifiées et un traitement asynchrone, la logique métier réelle est exécutée uniquement une fois ?
Si tel est le cas, vous pouvez utiliser un stockage centralisé (tel que redis) pour enregistrer l'enregistrement de la demande de l'appelant. Après avoir reçu la demande, le serveur utilise des opérations de requête atomique et de sauvegarde (telles que la commandesetnx de redis). , pour garantir qu'une seule demande sera enregistrée avec succès. Cela peut avoir pour effet de n'exécuter l'activité réelle qu'une seule fois.
Je n'ai aucune expérience dans ce domaine, mais l'approche de l'entreprise consiste à utiliser l'IP pour porter des jugements, et seule l'IP désignée peut exécuter cette tâche planifiée.
Ce qui suit est un fantasme personnel sans expérience pratique :
Créez une application publique spécifiquement pour gérer les tâches planifiées, puis fournissez une interface de message pour que des applications spécifiques puissent l'appeler.
Utilisez des transactions pour l'implémenter, des transactions distribuées ou des files d'attente de messages
Rendre l'opération elle-même idempotente, comme changer l'opération +1 en = opération
Donnez à chaque opération un identifiant et enregistrez chaque exécution Avant l'exécution, vérifiez si l'opération avec cet identifiant a été exécutée auparavant
Vous pouvez envisager une file d'attente de messages avec un mécanisme d'accusé de réception, tel que RabbitMQ, etc., qui garantit non seulement qu'une tâche n'est assignée qu'à un seul travailleur, mais garantit également l'intégrité du succès de la tâche
Nous y parvenons grâce à la planification zk. Dans un environnement distribué, une tâche ne peut être exécutée que par une seule machine au maximum. ZK peut très bien réaliser cette fonction
.Toutes les réponses jusqu'à présent sont fausses, y compris celle acceptée. La raison en est que les tâches planifiées ou les traitements asynchrones n’ont rien à voir avec l’idempotence.
redis + jeton suffit
Utilisez une file d'attente. Une fois que vous l'aurez prise, elle ne sera exécutée qu'une seule fois. Si l'exécution échoue, elle sera renvoyée dans la file d'attente et attendra la prochaine fois
.