Riprova architettura

3

Questo è stato a mio avviso poiché ho sviluppato diverse applicazioni con questa funzione.

Supponiamo che sia richiesta un'applicazione per elaborare le richieste in entrata in modo asincrono. Prendiamo l'esempio di un sistema di notifica (altri agenti invieranno una richiesta di notifica per notificare le persone via email o testo, ecc.) In questo caso questa applicazione richiede di chiamare altri sistemi esterni (server smtp nel nostro esempio). Questi sistemi esterni potrebbero essere temporaneamente disattivati, pertanto è necessario un nuovo meccanismo (fino a un certo numero di tentativi).

Ci sono biblioteche che offrono un modo per riprovare, come Polly. L'idea è che l'applicazione ritenterà X volte con ritardo D. Ma il problema è che l'elaborazione della richiesta viene eseguita in memoria durante tutto il processo di ripetizione, rendendo la risorsa inefficiente.

Quale sarebbe uno schema plausibile per questo tipo di problemi? Quali sono alcune considerazioni o piattaforme che dovrei esaminare? Che cosa hai fatto quando hai affrontato un problema simile?

Ogni volta che ho affrontato questo problema, l'ho risolto con una tabella che contiene le attività che devono essere elaborate. Li elaboro in batch e aggiorno i loro stati (NEW, IN_PROGRESS, ERROR). Questo meccanismo è utile per avere un'istanza, ma una volta che ho più istanze, il blocco della tabella è necessario in modo che nessuna istanza non elabori la stessa richiesta. Sembra che ci sia una soluzione migliore per questo problema.

    
posta Husain 12.01.2018 - 23:31
fonte

1 risposta

1

Nel tuo esempio, se l'invio della notifica fallisce, e non volevo utilizzare una libreria di terze parti per riprovare a inviarlo, lo aggiungerei a una coda con il tempo necessario per riprovare.

Potresti quindi avviare un tentativo di tutte le notifiche in coda in un paio di modi. È possibile avere un singolo thread che periodicamente esegue il polling della coda per eventuali attività in attesa. Se ce ne sono, controlla se è il momento di elaborarlo e, in caso affermativo, lo rimuove e lo elabora. Anziché eseguire periodicamente il polling, quando aggiungi una notifica alla coda dei tentativi, puoi configurare il thread per eseguire il polling dopo il tempo minimo dei tentativi di tutte le notifiche nella coda.

Dovresti bloccare la coda perché stai accodando le notifiche e iterando attraverso la coda, eventualmente in concomitanza con thread diversi.

Molte lingue forniscono una sorta di costrutto evento programmato che potresti usare anche tu, e questa sarebbe la mia prima scelta se riuscissi a trovarne una. So che puoi utilizzare un% pianificato% co_de in Java, ma. NET probabilmente ha qualcosa di simile.

Se le tue notifiche sono particolarmente grandi e la larghezza di banda del disco non è di primaria importanza per te, puoi scrivere il contenuto della notifica su un file o una voce del database e mantenere un riferimento a quel file o alla voce del database nella coda.

    
risposta data 13.01.2018 - 20:02
fonte