2011-09-24 12 views
5

Sto costruendo un sistema di accodamento che trasmette un messaggio da un processo a un altro tramite uno stack implementato in mongodb con capped_collections e cursori disponibili.Domanda su collezioni con limite mongodb + cursori disponibili

I processi di ricezione eseguono cicli infiniti alla ricerca di nuovi documenti nella capped_collection e quando ne trova uno esegue un'operazione.

La mia domanda è: se implemento più processi di ricezione esiste un modo per garantire che un nuovo documento venga letto una sola volta da uno dei processi utilizzando un cursore t disponibile? L'obiettivo è evitare che l'operazione venga eseguita due volte se ci sono due processi di ricezione che cercano nuovi messaggi nella coda. Sono relativamente nuovo alla programmazione di mongodb, quindi ho ancora un'idea di tutte le sue funzionalità.

risposta

2

MongoDB documents contengono una descrizione approfondita dei modi per ottenere un aggiornamento atomico. Non è possibile garantire che solo un processo riceva il nuovo documento ma è possibile implementare un aggiornamento atomico dopo averlo ricevuto per garantire che solo un processo agisca su di esso.

+0

La domanda riguardava il fatto che due cursori disponibili non corrispondessero mai allo stesso messaggio. Non vedo come questo abbia qualcosa a che fare con gli aggiornamenti atomici o con il collegamento alla documentazione che hai fornito – mysomic

+0

Hai downvoted perché non capisci la risposta * accettata *? Forse * tu * non capisci come usare gli aggiornamenti atomici per "evitare che l'operazione venga eseguita due volte", ma la persona che ha fatto la domanda lo ha chiaramente fatto. Bello. –

+1

Capisco la domanda e la tua risposta. Gli aggiornamenti atomici non * garantiranno che un nuovo documento verrà letto una sola volta da uno dei processi utilizzando un cursore t disponibile "* in quanto entrambi i consumatori ** riceveranno ** lo stesso documento. Il modo in cui coordinano entrambi dopo aver ricevuto un duplicato del documento di coda è un'altra questione e forse gli aggiornamenti atomici potrebbero essere coinvolti in qualche modo. Il fatto che sia la risposta accettata è irrilevante perché è quella corretta. – mysomic

0

Recentemente ho esaminato questo problema e sarei interessato a sapere se ci sono altri modi per avere più lettori (consumatori) senza fare affidamento sugli aggiornamenti atomici.

Questo è quello che ho trovato: dividere la logica in due "moduli". Il primo modulo sarà responsabile del recupero di nuovi documenti dal cursore tailable. Il secondo modulo sarà responsabile del lavoro con un documento arbitrario. In questo modo, è possibile avere un solo utente (modulo uno) che preleva i documenti che in seguito invia il documento a più lavoratori documento (secondo modulo).

Entrambi i moduli possono essere implementati in processi diversi e anche in lingue diverse. Ad esempio, un'app Node.js potrebbe recuperare i documenti e inviarli a un pool di script scritti in Python pronti per elaborare i documenti contemporaneamente.

+0

Sembra che tu possa essere interessato a Gearman. http://gearman.org/ –