2012-08-13 5 views
7

Sto cercando un buffer persistente semplice come memoria temporanea per i messaggi JSON in un'applicazione Java. L'utilizzo della memoria dovrebbe essere relativamente costante e non dipendere dal numero di messaggi nel buffer. Sarebbe bello essere in grado di riprodurre i messaggi da un punto nel passato. La cancellazione dei vecchi messaggi dovrebbe essere efficiente. Deve essere in grado di gestire messaggi di 1 m/h.Ricerca di un buffer dei messaggi persistente semplice in Java

Attualmente la mia applicazione utilizza un broker RabbitMQ locale che sposta i messaggi su un broker RabbitMQ remoto. Quando il broker remoto è inattivo o non accetta i messaggi, l'utilizzo della memoria del broker RabbitMQ locale aumenta con la lunghezza della coda e alla fine smette di accettare messaggi. Voglio scambiarlo con un buffer locale basato su disco e un thread che copia i messaggi sul broker RabbitMQ remoto.

Qualcuno ha qualche idea? Ho guardato Kafka ma sembra eccessivo per il mio caso d'uso. MongoDB è una possibilità, ma sono preoccupato per il suo utilizzo della memoria.

+0

Non sicuro ma forse Redis? Supporta anche pub/sub ... –

+0

redis è veloce ma ha bisogno di tanta memoria. controllalo. http://nosql.mypopescu.com/post/1010844204/redis-memory-usage –

+0

Potresti prendere in considerazione qualcosa come https://github.com/peter-lawrey/Java-Chronicle È progettato per supportare oltre 10 milioni di messaggi al secondo, ma devi ruotare i file per eliminarli. –

risposta

2

L'utilizzo della memoria è sempre un problema in qualsiasi sistema. Sto usando MongoDB per la produzione e quando mi confronto con soluzioni simili (CouchDB, CouchBase, redis.io), MongoDB è veramente buono nella gestione della memoria e nella facilità di implementazione. Ma dovrei ammettere, non ho mai avuto la possibilità di testare Riak in modo più dettagliato.

Sto memorizzando 5.000.000 record utente con 4 campi indice e tutte le sessioni utente dietro api di servizio web/di ripristino che utilizzano un servizio di messaggistica dietro.

Il servizio di messaggistica utilizza un'altra istanza di db sullo stesso server. I miei record utente hanno almeno 20 campi e record di sessione hanno solo 5 campi. I miei server ubuntu non hanno mai utilizzato più di 10 GB di ram anche con processi di caricamento pesanti.

Spero che questo aiuti a capire.

ps: tutto dipende dal modello di dati e dalla modalità di implementazione dell'infrastruttura.

saluti,

EDIT:

Credo this è una buona presentazione su come utilizzare MongoDB per la messaggistica.

e un bel article su MongoDB e messaggistica.

È possibile utilizzare il codice di prova e vedere i risultati sono ok per la soluzione. Si prega di non dimenticare di condividere i risultati se si esegue il test.

+1

Ho finito per scrivere un server di messaggi persistenti con il materiale di riproduzione di cui avevamo bisogno. Checkout http // qdb.io / –