Elaborazione code e code di database

Question

Attualmente sto mettendo insieme un'architettura di riferimento per un sistema basato su eventi distribuiti in cui gli eventi sono archiviati in un database di SQL Server di Azure utilizzando semplici tabelle (senza SQL Server Service Broker).

Gli eventi verranno elaborati utilizzando i ruoli di lavoro che eseguiranno il polling della coda per i nuovi messaggi di evento.

Nella mia ricerca, vedo un numero di soluzioni che consentono a più processori di elaborare i messaggi fuori dalla coda. Il problema che ho con molti dei modelli che vedo è la complessità aggiuntiva della gestione del blocco, ecc. Quando più processi tentano di accedere alla coda dei messaggi singoli.

Sono consapevole del fatto che il modello di coda tradizionale prevede l'estrazione di più processori da una singola coda. Tuttavia, supponendo che i messaggi degli eventi possano essere elaborati in qualsiasi ordine, c'è qualche ragione per non creare solo una relazione uno-a-uno tra una coda e il suo processore di coda e solo il bilanciamento del carico tra le diverse code?

queue_1 => processor_1
queue_2 => processor_2

Questa implementazione evita tutto l'impianto idraulico necessario per gestire l'accesso concorrente alla coda tra più processori. L'editore di eventi può utilizzare qualsiasi algoritmo di bilanciamento del carico per decidere su quale coda pubblicare i messaggi.

Il fatto che io non veda questo tipo di implementazione in nessuna delle mie ricerche mi fa pensare che sto trascurando un deficit maggiore in questo progetto.

Modifica

Questo post è innescato un dibattito sulla utilizzando le tabelle del database come code vs MSMQ, Azure code, ecc ho capito che ci sono una serie di opzioni di accodamento nativo a mia disposizione, tra cui messaggio durevole Buffer in AppFabric di Azure. Ho valutato le mie opzioni e ho stabilito che le tabelle SQL Azure saranno sufficienti. L'intenzione della mia domanda era di discutere l'uso di più processori contro una singola coda rispetto a un processore per coda.

Answer 1

Le tabelle come code sono abbastanza facili da fare. Vedere la mia risposta SO qui per favore: SQL Server Process Queue Race Condition

Answer 2

Come detto da S.Lott, ci sono meccanismi di coda messaggi che è possibile utilizzare. MSMQ non sarà di grande aiuto in Windows Azure, ma Windows Azure ha già un meccanismo di coda affidabile. È possibile impostare facilmente ciascuna istanza del ruolo di lavoro per leggere uno (o più) elementi della coda. Una volta che un elemento della coda viene letto, è "invisibile" per il periodo di tempo specificato (o 30 secondi se non è specificato il tempo). I messaggi in coda possono essere fino a 8K e sono considerati "duraturi": tutto lo spazio di archiviazione di Azure viene replicato almeno 3 volte (come SQL Azure).

Mentre è possibile implementare qualcosa di simile a ciò che descrive gbn, penso davvero che si dovrebbe prendere in considerazione il servizio nativo di Azure Queue quando si lavora in Windows Azure. Sarai facilmente in grado di ridimensionare a più utenti della coda e non dovrai preoccuparti della concorrenza o di un codice di bilanciamento del carico speciale - basta aumentare (o diminuire) il conteggio delle istanze.

Per ulteriori informazioni sulle code Windows Azure, consulta lo Azure Platform Training Kit - ci sono diversi laboratori semplici che ti guidano attraverso le basi della coda.

Answer 3

Il punto che ti manca, a mio avviso, è che quando si utilizzano le code uno dei punti importanti è che gli ordini vengono salvati e qualsiasi cosa accada una volta in coda non andrà persa.

Ora il processo di polling può morire, hanno molti problemi diversi, non importa, la coda è il luogo in cui gli ordini sono sicuri.

Poller non richiede lo stesso livello di robustezza. Ad esempio, Postfix è un'implementazione molto sicura del trasporto di posta in cui le code di messaggi sono utilizzate in molti livelli (ogni sottosistema nell'applicazione che richiede un diverso livello di sicurezza comunica con gli altri con le code) - e si può spegnere la corrente non perderà alcuna posta, i lavoratori possono morire molto male, le mail non possono.

Modifica

Ciò significa che l'uso di base sta memorizzando un ordine, e ignorando quello che i lavoratori faranno con questo, quanti lavoratori sono ancora in vita, ecc Quindi l'unica ragione per gestire diverse code è quello di gestire diverse destinazioni per il tuo ordine (logica dell'applicazione) e non gestire il modo in cui gli operai dovrebbero lavorare con loro (disaccoppiamento).

Answer 4

Vedere Using tables as Queues per una discussione più dettagliata di questo argomento. Il problema non è solo il modo in cui si accede alla "coda", ma anche il modo in cui indicizzarlo, l'indice cluster deve consente la ricerca diretta della riga successiva da eliminare, altrimenti si bloccherà costantemente.

Se si desidera che i processori raggiungano la stessa coda, il bilanciamento del carico distribuito su code diverse è un anti-modello. Porta a convogli e latenza artificiale in cui sono presenti elementi accodati dietro un processore in ritardo, ma altri processori sono liberi e inattivi perché la loro coda è vuota nella loro .