Quale modello dovrei impostare per gestire l'evento come elemento di lavoro?

Question

Quale modello dovrei impostare per gestire l'evento come elemento di lavoro?

#1 da (1 voti)

2

Ho questo evento aziendale: "CustomerUpdated" pubblicato dal mio sistema.

Ho molte applicazioni che ascoltano questi eventi e fanno tutto il possibile: inviare e-mail, aggiornare il database, cancellare la cache ecc ... quindi non posso usare una coda qui, ma non posso usare una topic, perché se sono in esecuzione 2 istanze dell'applicazione di posta (le ho create per la scalabilità), l'email verrà inviata due volte: una per ogni istanza.

Quindi cosa dovrei fare:

ha un'istanza univoca che sta ascoltando l'evento e quindi pubblica un elemento di lavoro nella coda "SendCustomerUpdatedEmail"? : ma ciò aggiungerebbe un collo di bottiglia alla mia app (non una grande però)
salva un "CustomerUpdatedEmailsHandled" in una posizione centralizzata (db) e salva qui qualcosa che identifica l'evento (guid)
Un altro pattern davvero intelligente che non riuscivo a capire

PS: l'ho postato su link ma non ho ricevuto alcuna risposta (solo qualcuno mi ha detto che ho preso decisioni sbagliate ma senza soluzioni) e sembra che lo stackoverflow sia stato creato per" codificare " domande così ...

event-programming message-queue

posta remi bourgarel 01.08.2016 - 15:26

fonte

1 risposta

Leggi altre domande sui tag event-programming message-queue

Come gestire i test unitari con i collaboratori e gli effetti collaterali? Progettazione API: come specificare un albero arbitrario?

score 1 · Answer 1

In realtà hai descritto esattamente cosa dovresti fare nella tua prima soluzione suggerita: se hai più app che ascoltano lo stesso evento, devi assolutamente usare un approccio basato su argomenti. Detto questo, la scalabilità non dovrebbe essere risolta solo sul lato sorgente, ma anche sul lato destinatario. Ciò significa che ogni applicazione dovrebbe avere la propria coda e ottenere eventi da lì.

Considerando che questa coda è solo una struttura a flusso continuo, non dovrebbe essere un collo di bottiglia. Se si dimostra che è così, puoi sempre aggiungere più potenza di elaborazione e magari progettare una sorta di pubblicazione di dati round robin (questa è la parte in cui la scalabilità è implementata da un lato sorgente). L'idea sarebbe che avresti n SendCustomerUpdatedEmail code e un evento dall'argomento verrà pubblicato su una di quelle code, associate a un'istanza dell'applicazione SendCustomerUpdatedEmail . In questo modo, il messaggio verrebbe inviato a una sola istanza della coda ed elaborato solo una volta, mentre altre istanze sarebbero rimaste disponibili per altri eventi contemporaneamente.