Gestione del download di dati che potrebbe richiedere giorni per il download

Question

Gestione del download di dati che potrebbe richiedere giorni per il download

#1 da (0 voti)
#2 da (0 voti)

-1

Ho una situazione sul front-end in cui un utente fa clic sul pulsante "Download" e la query dietro le quinte sta per prendere in carico un giorno. Ho un'applicazione web di avvio Spring in esecuzione per quanto riguarda i servizi Web.

Cosa voglio:

Quando si fa clic sul pulsante di download sul front-end, vorrei mettere questo processo in una sorta di coda. Credo che mettere in coda sia l'unica opzione. E quando il download è completato, dovrebbe scaricare il file in qualche posizione del server.

Per fare questo, sono stato suggerito da qualcuno che dovrei usare JMS. Quindi, in sostanza, ho bisogno di integrare la funzionalità JMS con il servizio web RESTful. Non ho usato JMS prima e quindi mi chiedo:

1) JMS è un buon approccio da usare in questo scenario? 2) Se sì, allora ho bisogno di mettere questa cosa JMS parlare di uno specificamente servizio web, che nel mio caso precedente sarebbe il servizio web responsabile per il download delle cose quando si fa clic sul pulsante di download? 3) Qualsiasi altro approccio se possibile o consigliato su questo?

Per favore, fammi sapere se posso rispondere a più domande.

java spring spring-boot

posta John 01.11.2018 - 05:45

fonte

2 risposte

Leggi altre domande sui tag java spring spring-boot

Differenze tra la digitazione di token gerarchico e basata sull'enumerazione Mappatura di oggetti Data Transfer sulla mia classe del modello

score 0 · Answer 1

Il tuo istinto di salvare qualche stato riguardo questo download è un approccio corretto. Generalmente le code e i database si sovrappongono. Ad esempio, è abbastanza semplice implementare alcune parti di una coda di messaggi utilizzando un database. Dove le code brilla davvero è quando abbiamo bisogno di ottenere un numero elevato di messaggi per un consumatore con bassa latenza (pochi millisecondi). L'utilizzo di un database come questo spesso implica il polling che riduce la latenza a forse un minuto.

Se sei più a tuo agio nell'usare un database e puoi vivere con un po 'di latenza extra (sembra possibile quando parliamo di giorni), allora usa assolutamente un database per questo.

score 0 · Answer 2

Poiché hai già un'API RESTful, progetterei questa funzione come descritto di seguito. Presumo che tu stia creando una sorta di rapporto, che richiede molto tempo per essere preparato, ma non è poi così grande dopo che è stato creato.

Il servizio API fornisce una risorsa "FooReport" che rappresenta sia lo stato del report che il suo contenuto. Queste risorse sono servite sotto l'endpoint /foo/reports/
Quando l'utente preme il pulsante "Download", il frontend invia una richiesta POST a /foo/reports/ per attivare la creazione di un nuovo report.
Il servizio API crea una nuova risorsa FooReport, attiva un servizio in background per iniziare a creare il report (è qui che JMS potrebbe entrare in gioco o semplicemente aggiunge una voce a una tabella specifica nel database) e segnala l'URL (ad esempio /foo/reports/42 ) alla risorsa appena creata torna al front-end.
Il front-end può controllare periodicamente lo stato della risorsa FooReport o su richiesta dell'utente inviando una richiesta GET a /foo/reports/42 .
Una volta creato il rapporto, esistono diverse possibilità per informare l'utente che il contenuto è ora disponibile, a seconda di quanto è critico che l'utente riceva una notifica tempestiva.
1. Il servizio in background causa l'invio di una e-mail con il report e / o un link per il download al richiedente
2. Se l'utente può ricevere messaggi push (ad esempio attraverso websocket in un'applicazione web), allora quel canale può essere usato per avvisare l'utente che il rapporto è pronto
3. Quando il front-end successivo richiede lo stato della risorsa, lo stato indica che il contenuto è disponibile, sia in linea nella rappresentazione della risorsa o come collegamento per il download.

In questa progettazione, ci sono tre parti: - Il front-end che fornisce l'interfaccia utente all'utente - Il servizio API che fornisce un'API REST - Il servizio in background che fa il sollevamento pesante

A seconda del numero di richieste simultanee per la creazione di FooReport, potrebbero essere necessarie più istanze del servizio in background e si deve pensare di garantire che ogni istanza di servizio funzioni su un report diverso.
Per un basso numero di richieste simultanee, solo la registrazione dello stato nel database come 'in sospeso', 'elaborazione', 'creata' dovrebbe essere sufficiente e ciò rende anche facile per il servizio API segnalare lo stato corretto.