server - java web定时任务

Answer 1

Personnellement, j'estime que tout le timing du logiciel est effectué via des sondages, et l'ouverture d'un fil pour effectuer une telle tâche consomme plus de ressources. Je pense que la solution suivante peut avoir de meilleures performances.

0. Tout d'abord, nous avons besoin d'une "diffusion programmée" qui envoie une diffusion toutes les 5 minutes
1 Lorsqu'un utilisateur s'inscrit, nous enregistrons un auditeur pour écouter la "diffusion programmée"
2. utilisateur Cliquez sur l'adresse d'activation dans l'email pour fermer l'auditeur précédemment enregistré
3. Si l'auditeur reçoit la diffusion pour la deuxième fois, la tâche sera exécutée et l'écoute sera annulée

La raison pour laquelle la tâche doit être exécutée lorsque la diffusion est reçue pour la deuxième fois est de garantir que la tâche peut être exécutée après 5 à 10 minutes. Bien entendu, cela ne peut pas garantir un timing précis. Si vous devez améliorer la précision du timing, vous pouvez diffuser une fois par minute, voire une fois par seconde, mais ce scénario ne devrait pas être nécessaire.

Pour mettre en œuvre une diffusion programmée, vous pouvez utiliser des outils tels que Quartz, ou même utiliser des files d'attente de messages pour séparer cette activité.

J'espère que cela vous aidera, n'hésitez pas à commenter s'il y a des choses inappropriées ou erronées

Answer 2

Utilisez la base de données pour interroger et supprimez l'enregistrement correspondant si vous cliquez dessus

Answer 3

Utilisez le minuteur de Spring pour le compléter au niveau de la couche de service. Il y a un champ dans la base de données qui est 0 lors de l'enregistrement, le minuteur de Spring est appelé Après cinq minutes, ce champ dans la base de données sera analysé toutes les quelques secondes. et généré. L'utilisateur du code de vérification a cliqué sur l'adresse dans la boîte aux lettres pour arrêter le chronomètre. Je peux vous donner la documentation et le code du temporisateur à ressort

.

Collez une section des minuteries et déclencheurs natifs de jdk. Timer et TimerTask sont les points clés. Enregistrez l'écouteur lorsque le minuteur appelle le planning ou l'appelez par d'autres méthodes. Pour plus d'informations, veuillez vous référer au développement du JDK. documentation. Il y a des instructions détaillées dans la documentation. Ma petite démo n'a pas annulé la tâche.

import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.Timer;
import java.util.TimerTask;

public class Demo {
    public static void main(String[] args) {
        Timer timer = new Timer();
        Long long1 =new Long("1486308200000");
        timer.schedule(new TaskDemo(), new Date(long1));
    }
}

class TaskDemo extends TimerTask{
    @Override
    public void run() {
        System.out.println("点前时间是"+new SimpleDateFormat("yyyyMMddHHmmss").format(new Date()));
    }
}

Answer 4

Ce type de minuterie ponctuelle est plus approprié pour être implémenté à l'aide d'une file d'attente de messages. Il est relativement simple à implémenter et il existe des solutions matures. La chose la plus indispensable en Java est la roue. Files d'attente de messages telles que : RabbitMQ, ActiveMQ, RocketMQ

Answer 5

Il y a quelque chose qui ne va pas avec votre conception :

1. Selon votre conception, l'inscription de chaque utilisateur doit démarrer une tâche planifiée, et si un grand nombre d'utilisateurs s'inscrivent ? Une tâche planifiée est en fait un thread. Démarrer un grand nombre de threads consommera trop de ressources CPU.

2. L'utilisateur clique sur l'adresse email pour activer l'adresse puis la détruire. Si vous stockez des tâches planifiées dans la JVM, elles risquent d'échouer lors du déploiement du cluster, car vous ne pouvez pas garantir que les utilisateurs accèdent à la même instance JVM lors de l'enregistrement et de l'activation.

3. La tâche planifiée détecte que l'utilisateur n'est pas activé, puis régénère le code de vérification. Pourquoi devrait-il être généré avant que l'utilisateur clique ensuite pour envoyer un e-mail ?

Je pense qu'un meilleur design devrait ressembler à ceci :

1. Inscription de l'utilisateur, statut d'activation de l'utilisateur = Non

2. L'utilisateur clique sur [Envoyer un e-mail d'activation], et l'url d'activation est générée en arrière-plan. L'url est accompagnée d'un uuid. Cet uuid est associé au nom d'utilisateur, stocké (uuid, nom d'utilisateur, expiration. heure), puis l'email est envoyé

3. L'utilisateur clique sur l'url d'activation dans l'e-mail et accède à votre application

4. Votre application obtient l'uuid dans l'URL pour voir si elle existe dans la base de données et n'a pas expiré. Si oui, obtenez le nom d'utilisateur associé, mettez à jour le statut d'activation de l'utilisateur = true et supprimez l'uuid ; si non, ne faites rien ;

stockage uuid :

1. peut être stocké dans la base de données, mais afin de nettoyer les données expirées, vous pouvez ouvrir un thread séparé (un seul) et l'exécuter toutes les 1 minute pour supprimer l'uuid expiré dans la base de données.

2. peut également être stocké dans Redis. Redis a une fonctionnalité qui vous permet de spécifier le ttl des données. Elles seront automatiquement supprimées à leur expiration, il n'est donc pas nécessaire d'ouvrir un fil de discussion séparé pour nettoyer le. UUID expiré.