Attività Architettura consumer / processore

1

PROBLEMA

Nel nostro sistema abbiamo vari compiti che possono richiedere fino a 20 minuti. Queste attività sono generalmente avviate dall'interfaccia web ed eseguite su un nuovo thread. Questa è ovviamente una soluzione terribile perché l'attività potrebbe essere riciclata da IIS e utilizza risorse preziose sul server web.

POSSIBLE SOLUTION

Ospitare una classe TaskConsumer in un servizio Windows (o nel ruolo di un operaio di Azure, nel nostro caso), che preleva le attività e le elabora. Questo gestirà l'accodamento e l'esecuzione delle attività.

Le nuove attività vengono aggiunte a una tabella di database (ad esempio Tasks ) nel codice client tramite alcune classi TaskManager ( TaskManager.Enqueue(ITaskable) ), che vengono quindi rilevate da TaskConsumer (forse sta interrogando questa tabella per aggiunte?). Questa tabella verrebbe anche aggiornata dal TaskConsumer mentre l'attività è in esecuzione (forse un campo stato - RUNNING , QUEUED , FAILED , COMPLETE ).

Per creare un nuovo tipo di attività, si implementerebbe un'interfaccia ITaskable . Ciò richiederebbe implementazioni per un metodo Process() , che conterrebbe la logica per eseguire quell'attività.

Un'interfaccia utente potrebbe mostrare tutte le attività attive e forse fornire alcune funzionalità di gestione (ad esempio, annullare un'attività, riavviare un'attività, ecc.). Queste informazioni possono essere recuperate dalla classe TaskManager ( TaskManager.ActiveTasks ), che essenzialmente sta leggendo dalla tabella del database Task .

Le implementazioni concrete di ITaskable dovrebbero avere proprietà serializzabili così da essere memorizzate nel database. Questo è necessario perché ci sarebbero parametri / dati specifici necessari per eseguire l'attività. Ad esempio, un compito ImportEmployees dovrebbe avere il nome del file che è stato originariamente caricato. Questo dovrebbe essere noto al momento in cui il consumatore deve eseguire l'attività (per la desializzazione).

È un buon approccio per affrontare questo problema?

Sono sicuro che ci devono essere molti schemi là fuori per questo tipo di problema.

    
posta davenewza 27.09.2013 - 11:44
fonte

1 risposta

1

Va bene. Si imbattono nel problema che i consumatori devono eseguire martellando inutilmente il DB per cercare attività, annullamenti delle attività, ecc. Avrei il task manager creare una voce nel DB per l'attività in modo che l'utente delle attività abbia un luogo dove riportare i risultati . Quindi utilizzare una coda di messaggi come MSMQ o ActiveMQ per eseguire il controllo effettivo del consumer delle attività. Probabilmente non andrei a cercare i risultati segnalati sulla coda dei messaggi perché si dovranno scrivere (e leggere) i risultati nel DB solo in caso di scarico del processo. È molto più semplice leggere sempre i risultati dal DB.

Se il carico del tuo DB non è così elevato o non vuoi complicare la tua implementazione lanciando un altro bit di software, la tua progettazione funzionerà perfettamente. Basta fare attenzione a non uccidere il DB che ha il compito dei consumatori martellare troppo duro.

    
risposta data 27.09.2013 - 16:18
fonte

Leggi altre domande sui tag