Design periodico sistema di notifica batch

4

Problema:

  • Sto cercando di progettare un sistema che raccolga le richieste dei clienti in tempo reale e registrarli in un database. Ad esempio: richiesta a acquista un oggetto.
  • Il cliente ottiene quindi un ID di richiesta univoco per la sua richiesta e anche viene chiesto di attendere "X" giorni perché la richiesta è in fase di elaborazione.
  • Quindi il sistema avvisa i fornitori degli articoli raggruppando tutti questi elementi richieste in un'unica email periodicamente (diciamo 4 ore).
  • I fornitori di articoli aggiornano gli elementi nel loro repository e li pubblicano clienti. E poi il cliente riceve una notifica dai fornitori di articoli hanno risposto per la sua richiesta.

Design:

I'm thinking of using a workflow based system for this use case. With following components (high level) -

Synchronous API:
 - Receive request from customer. 
 - Record the request in the database.
 - Also start an asynchronous workflow, return request id as a response.

Workflow does the following :

Workflow Step 1:
 - Get the list of item providers
 - Notify them

Workflow Step 2: (This workflow steps gets executed after "X" days)
 - Send a response email back to the customer

But I'm having hard time to support the batching use-case. Is there any way I can efficiently batch the customer requests and send notification every 4 hours without having to write a cron job separately?

Apprezzerei qualsiasi suggerimento / aiuto su questo.

    
posta Kevindra 13.08.2015 - 02:00
fonte

3 risposte

1

Questo è molto semplice: le richieste per il processo di un compito vengono eseguite normalmente - tutto ciò che accade è che una voce viene scritta in un DB con un timestamp su di esso. Trivial da implementare.

Altrove nel tuo programma, hai una discussione che va a dormire per il tempo richiesto, si sveglia dopo 4 ore, legge tutte le attività in sospeso e le invia ai fornitori.

Lo stesso vale per le risposte: il fornitore invia una risposta nel sistema che lo scrive su un DB. Periodicamente un'attività si riattiva, legge tutte le risposte in sospeso e invia un'email al cliente.

Ora puoi ottimizzarlo, come dovresti vedere i passaggi sono gli stessi sia per il cliente che per il fornitore. È possibile configurare un sistema che riceve richieste e scrive dati nel DB e qualcos'altro che è responsabile della lettura e dell'invio delle risposte. Se poi si ottimizza ulteriormente, è possibile utilizzare un sistema esterno come cron per gestire l'elaborazione di attivazione: tutto ciò che deve fare è inviare una richiesta al sistema che attiva l'elaborazione.

Quindi è sufficiente programmare una piccola quantità di architettura che viene riutilizzata per la richiesta del cliente e la risposta del fornitore; e le voci di attivazione e di elaborazione. Questo è principalmente il punto di elaborazione in batch, lo si mantiene molto semplice e riutilizzare lo stesso processo per elaborare dati diversi.

    
risposta data 15.02.2016 - 11:19
fonte
0

Il tuo design sembra che possa trarre vantaggio da Messaggistica asincrona

I messaggi possono essere inviati attraverso diverse pipeline a più applicazioni di ricezione e programmati per l'esecuzione in un determinato momento (la pianificazione può essere una funzionalità integrata del bus dei messaggi (middleware) o può essere elaborata nella soluzione (rispondere con con un messaggio ID compito shceudled e inviare l'attività a un'applicazione diversa da eseguire in seguito)

I batch possono verificarsi all'interno di questa architettura come un'app di gateway che raccoglie i messaggi con determinati valori di proprietà, li raggruppa e li invia come un messaggio diverso (il messaggio batch) ogni intervallo di tempo.

Ora so che ciò che ho spiegato qui è molto astratto, ma tenete presente che nemmeno spiegare l'intera architettura qui non sarebbe pratico.

Spero che questa risposta possa spingerti a leggere di più sul modello di architettura per Messaging, e sarei felice di rispondere ad altre domande più specifiche più tardi.

    
risposta data 19.08.2015 - 05:31
fonte
0

Puoi farlo con: 1) Avvia il programma standalone script java / perl / shell con cron alle 00:01 e il programma termina alle 23:59 ogni giorno lavorativo.

Nel programma è possibile leggere un file di configurazione per dormire per l'intervallo che ti serve. Questo lo rende dinamico poiché puoi cambiare la configurazione in qualsiasi momento. Inoltre, puoi aggiungere ulteriori funzionalità nel programma stand alone in futuro.

Quindi lo pianifichi solo una volta. Questo ti dà la possibilità di ucciderlo in qualsiasi momento al prompt dei comandi e il riavvio è facile.

Vorrei sconsigliare l'utilizzo dello scheduler del database.

    
risposta data 16.03.2016 - 12:25
fonte

Leggi altre domande sui tag