2012-08-13 16 views
7

Estoy buscando un búfer persistente simple como almacenamiento temporal para mensajes JSON en una aplicación Java. El uso de memoria debe ser relativamente constante y no depender de la cantidad de mensajes en el búfer. Sería bueno poder reproducir mensajes de un punto en el pasado. La eliminación de mensajes antiguos debe ser eficiente. Necesita ser capaz de manejar mensajes de 1 m/h.Buscando un búfer de mensaje persistente simple en Java

Actualmente mi aplicación utiliza un agente local RabbitMQ que envía mensajes a un intermediario RabbitMQ remoto. Cuando el intermediario remoto está inactivo o no acepta mensajes, el uso de la memoria del intermediario local RabbitMQ aumenta con la longitud de la cola y, finalmente, deja de aceptar mensajes. Quiero cambiar esto por un búfer basado en disco local y un hilo que copie mensajes en el broker RabbitMQ remoto.

¿Alguien tiene alguna idea? Miré a Kafka, pero parece excesivo para mi caso de uso. MongoDB es una posibilidad pero me preocupa su uso de memoria.

+0

No estoy seguro, pero tal vez Redis? Es compatible con pub/sub también ... –

+0

redis es increíblemente rápido, pero necesita tanta memoria. mira esto. http://nosql.mypopescu.com/post/1010844204/redis-memory-usage –

+0

Puede considerar algo como https://github.com/peter-lawrey/Java-Chronicle Está diseñado para admitir más de 10 millones de mensajes por segundo, pero tienes que rotar los archivos para eliminarlos. –

Respuesta

2

El uso de memoria siempre es un problema en cualquier sistema. Estoy usando MongoDB para producción y cuando lo comparo con soluciones similares (CouchDB, CouchBase, redis.io), MongoDB es realmente bueno en administración de memoria y facilidad de implementación. Pero debo admitir que nunca tuve la oportunidad de probar más a Riak en detalle.

Estoy almacenando 5.000.000 de registros de usuario con 4 campos de índice y todas las sesiones de usuario detrás de una API de servicio/resto que utiliza un servicio de mensajería.

Mi servicio de mensajería usa otra instancia de db en el mismo servidor. Mis registros de usuario tienen al menos 20 campos y los registros de sesión tienen solo 5 campos. Mis servidores de ubuntu nunca usaron más de 10 GB de carneros, incluso con procesos de carga pesados.

Espero que esto ayude a descubrirlo.

ps: todos dependen del modelo de datos y de cómo implemente su infraestructura.

Saludos,

EDIT:

Creo this es una buena presentación sobre el uso de MongoDB para la mensajería.

y un agradable article sobre MongoDB y mensajería.

Puede usar el código de prueba y ver que los resultados están correctos para su solución. No olvide compartir sus resultados si prueba.

+1

Terminé escribiendo un servidor de cola de mensajes persistente con las cosas de repetición que necesitábamos. Checkout http // qdb.io / –

Cuestiones relacionadas