Progetta una soluzione accodamento con cluster e più utenti

È possibile suddividere facilmente i dati con hashing coerente, in questo caso si utilizzerà l'entità come chiave hash. L'hash coerente prende una chiave e un numero di "bucket" come input e ti restituisce il bucket per quella chiave.

Con più server in mente, una soluzione semplice sarebbe quella di selezionare un numero di partizioni in primo piano (diciamo 6), il che significa che avrai 6 code. Quando produci messaggi, calcola il bucket [consistentHash (entity.id, 6)] e metti il messaggio in coda (partizione) che corrisponde a quel bucket. Questo ti dà l'ordine dei messaggi per entità.

Dal punto di vista del consumatore, assicurati semplicemente di avere esattamente un consumatore per coda (partizione). Puoi avere tutti i server che vuoi finché non ci sono consumatori in competizione.

Puoi quindi fare un ulteriore passo avanti all'interno di ogni server per migliorare il parallelismo. Il consumatore di ogni coda (partizione) può essere un router, che prende semplicemente ogni messaggio e fa un altro hash coerente sull'entità, a N bucket in cui N è il numero dei thread di lavoro che vuoi per il parallelismo, quindi passa il messaggio a il thread per il bucket calcolato.

Questa impostazione indirizza i messaggi per la stessa entità in modo coerente allo stesso server e il server instraderà coerentemente il messaggio allo stesso thread di lavoro. Supponendo che i thread N worker siano relativamente alti, ottieni un'eccellente parallelizzazione delle tue attività con l'ordinamento dei messaggi basato su qualsiasi chiave che desideri.

Non è necessaria alcuna operazione DB per la sincronizzazione tra le operazioni.

Se sono necessarie tutte e 3 le operazioni da eseguire sui dati in sequenza:

Invia i tuoi dati alla coda A, che ha consumatori che eseguono l'operazione A e alla fine di essa, li manda alla coda B. I consumatori in coda B eseguiranno l'operazione B e invieranno i dati alla coda C dove i consumatori aspetteranno per eseguire l'operazione C su di esso.

Se hai bisogno di tutte e 3 le operazioni da eseguire sui tuoi dati, ma la sequenza non è importante:

Mantieni solo una coda con 10 consumatori per ciascuna operazione (5 su ogni macchina) Aggiungi intestazioni OpA = true, opB = true, opC = true per i tuoi dati quando la aggiungi alla coda per la prima volta. I consumatori per l'operazione A dovrebbero selezionare solo quelli WHERE opA = true. Utilizza Consumatore selettivo per questo ( link ) Quando un consumatore riceve il messaggio, deve eseguire la rispettiva operazione, rimuoverlo rispettiva intestazione e rimanda i dati alla stessa coda (solo se ci sono altre intestazioni dopo aver rimosso la propria intestazione).

Questo sembra un caso classico per il modello di ciclo di indirizzamento .

Questo approccio è esattamente come hai descritto: code separate per ogni utente / processore di messaggi. Solo un consumatore può lavorare su un determinato messaggio ( Entity ) alla volta, ma i consumatori sono liberi di lavorare su tutti i messaggi che sono in coda.

Il vantaggio principale di questo approccio è che non devi conoscere la rotta del messaggio quando stai creando il codice. È possibile definire il routing di runtime in base al tipo di messaggio; carico sui singoli consumatori; o qualsiasi cosa abbia un senso per le tue esigenze.

I maggiori vantaggi di questo approccio sono:

• Ogni consumatore mantiene la sua indipendenza dagli altri consumatori. Un processo consumer di lunga durata può essere integrato singolarmente aggiungendo risorse aggiuntive. Se i tuoi consumatori lo supportano, è possibile aggiungere o spostare risorse aggiuntive in base ai carichi di lavoro correnti.

• Evitare la necessità di voci del database e blocco. In generale, i DB non gestiscono molto bene i messaggi di eventi su larga scala come questo. Puoi farlo funzionare, ma la soluzione tende a essere fragile e soggetta a rotture quando cambiano i requisiti.