2012-08-13 7 views
7

Ich bin auf der Suche nach einem einfachen persistenten Puffer als temporärer Speicher für JSON-Nachrichten in einer Java-Anwendung. Die Speicherbelegung sollte relativ konstant sein und nicht von der Anzahl der Nachrichten im Puffer abhängen. Es wäre schön, Nachrichten von einem Punkt in der Vergangenheit wiedergeben zu können. Das Löschen alter Nachrichten sollte effizient sein. Muss 1m Nachrichten/h verarbeiten können.Suche nach einfachen persistenten Nachrichtenpuffer in Java

Derzeit verwendet meine Anwendung einen lokalen RabbitMQ-Broker, der Nachrichten an einen entfernten RabbitMQ-Broker schaufelt. Wenn der Remote-Broker inaktiv ist oder keine Nachrichten akzeptiert, steigt die Speicherbelegung des lokalen RabbitMQ-Brokers mit der Warteschlangenlänge und hört schließlich auf, Nachrichten zu akzeptieren. Ich möchte dies für einen lokalen Datenträger-basierten Puffer austauschen und einen Thread, der Nachrichten an den entfernten RabbitMQ-Broker kopiert.

Wer hat irgendwelche Ideen? Ich habe Kafka angeschaut, aber es scheint mir ein Overkill für meinen Anwendungsfall zu sein. MongoDB ist eine Möglichkeit, aber ich mache mir Sorgen um die Speichernutzung.

+0

Nicht sicher, aber vielleicht Redis? Es unterstützt Pub/Sub auch ... –

+0

Redis ist blitzschnell aber braucht so viel Speicher. check das aus. http://nosql.mypopescu.com/post/1010844204/redis-memory-usage –

+0

Sie könnten etwas wie https://github.com/peter-lawrey/Java-Chronicle betrachten Es wurde entwickelt, um über 10M Nachrichten pro Sekunde zu unterstützen Sie müssen die Dateien drehen, um sie zu löschen. –

Antwort

2

Speicherverbrauch ist immer ein Problem in jedem System.Ich verwende MongoDB für die Produktion und wenn ich mit ähnlichen Lösungen (CouchDB, CouchBase, redis.io) vergleichen, ist MongoDB wirklich gut in Speicherverwaltung und Einfachheit der Implementierung. Aber ich gebe zu, ich hatte nie die Gelegenheit, Riak genauer zu testen.

Ich speichere 5.000.000 Benutzerdatensätze mit 4 Indexfeldern und alle Benutzersitzung hinter einem Rest/Web Service API, der einen Messaging-Dienst verwendet.

Mein Messaging-Dienst verwendet eine andere Datenbankinstanz auf demselben Server. Meine Benutzerdatensätze haben mindestens 20 Felder und Sitzungsdatensätze haben nur 5 Felder. Meine Ubuntu-Server haben nie mehr als 10 GB RAMs verwendet, selbst bei schweren Ladevorgängen.

Hoffe das hilft, herauszufinden.

ps: alle hängen von Datenmodell und wie Sie Ihre Infrastruktur implementieren.

Grüße,

EDIT: über die Verwendung von MongoDB für Messaging

Ich denke this eine gute Diashow ist.

und eine nette article über MongoDB und Messaging.

Sie können den Testcode verwenden und sehen, dass die Ergebnisse für Ihre Lösung in Ordnung sind. Bitte vergessen Sie nicht, Ihre Ergebnisse zu teilen, wenn Sie testen.

+1

Ich schrieb einen persistenten Nachrichtenwarteschlangenserver mit den Replay-Sachen, die wir brauchten. Auschecken http // qdb.io / –