Das System, das wir erstellen, empfängt Daten über den externen Feed. Unsere Aufgabe besteht darin, diese Daten an mehrere Dienste zu verteilen, die Berechnungen durchzuführen und die Ergebnisse an anderer Stelle weiterzuleiten - typische Situation bei Publishern und Abonnenten. Was wir brauchen, ist eine sehr niedrige Latenzzeit. Wir müssen die Nachrichten nicht wie MSMQ persistieren.
Ist RabbitMq schnell genug für eine reibungslose Echtzeit-Nachrichtenübermittlung? Gibt es Benchmarks? Ist es eine gute Idee, es anstelle von TIBCO Rendezvous zu verwenden? Gibt es andere Open-Source-Soft-Realtime-Messaging-Alternativen?
Danke.
(Ich bin ein Kaninchen mq Entwickler.)
Rabbit wird bei geringer Auslastung im Allgemeinen Latenzen in der Größenordnung von 100-400 Mikrosekunden haben, abhängig von der Netzwerkkarte und der CPU-Geschwindigkeit. Sobald das Laden etwas schwerer wird, beginnt die interne Pufferung zu erscheinen und die Latenzen steigen ein wenig an. Sie können sicher 1ms Latenzen erwarten, bis die Bandbreite (Nachrichten pro Sekunde, Bytes pro Sekunde) beginnt, hoch zu werden. Die Latenzzeiten werden ebenfalls steigen, sobald Persistenz eingeführt wird, natürlich.
Was Benchmarks betrifft, ist eines der größten Probleme hier zu definieren, was für Ihre Anwendung wichtig ist. Es gibt einige trivial einfache Point-to-Point- und Pub-Sub-Latenz- und Durchsatz-Messbeispiele, die im Java-Client enthalten sind. frag auf der rabbitmq-discuss-liste, wenn du probleme mit ihnen hast! Sie messen nicht viel von Relevanz für reale Anwendungen, können aber dazu beitragen, Bedenken hinsichtlich der Mikrobenchmarks von Latenz oder Durchsatz zu zerstreuen.
Schließlich gibt es heutzutage viele, viele gute Open Source Messaging- und Messaging-Systeme. In der Welt von AMQP gibt es neben RabbitMQ auch Qpid und OpenAMQ. Es gibt auch gute Open-Source-JMS-Server, wenn Sie sich auf Java beschränken können (viele Leute haben Erfolg mit ActiveMQ). Viele Systeme mit geringem Gewicht entwickeln sich auch für Ruby- und Python-Systeme; Diese Systeme konzentrieren sich in der Regel auf Warteschlangen und neigen nicht dazu, die flexible Routing-Funktion von AMQP zu nutzen.
Sie sollten in der Lage sein, viele Zehntausend Nachrichten pro Sekunde pro CPU zu erreichen. Zum Beispiel schiebt einer unserer Standardtests 25.000 Nachrichten pro Sekunde von einem Java-Client auf den Server, der auf einer Quad-Core-COTS-Debian-Box läuft, und zurück zum Client. Der Client und der Server werden auf derselben Box ausgeführt, sodass pro Sekunde 50.000 Nachrichten auf dem Server und 50.000 Nachrichten pro Sekunde auf dem Client verarbeitet werden. Sie können höhere Raten erzielen, indem Sie den Server auf einer dedizierten Box mit mehreren Kernen ausführen. Für Preise, die auf Bytes / Sekunde basieren, fragen Sie bitte auf der Mailingliste rabbitmq-discuss.
Alexis
Die beste Lösung, die ich über Ihr System denken kann, ist ZeroMQ .
Es hat keine Ausdauer, die Sie sagten, dass Sie nicht brauchen, und es ist sehr schnell und einfach zu bedienen.
Es handelt sich nicht um eine AMQP-Implementierung (die Sie anscheinend nicht brauchen), sondern wie auf dieses Handbuch :
ØMQ (ZeroMQ, 0MQ, zmq) sieht wie eine einbettbare Netzwerkbibliothek aus, funktioniert aber wie ein Parallelitätsframework. Es gibt Sockets, die ganze Nachrichten über verschiedene Transporte wie Inprozess, Interprozess, TCP und Multicast übertragen. Sie können Sockets N-to-N mit Mustern wie Fanout, Pub-Sub, Aufgabenverteilung und Anfrage-Antwort verbinden. Es ist schnell genug, um das Gefüge für Cluster-Produkte zu sein. Sein asynchrones E / A-Modell bietet Ihnen skalierbare Multicore-Anwendungen, die als asynchrone Nachrichtenverarbeitungsaufgaben erstellt werden. Es hat eine Reihe von Sprach-APIs und läuft auf den meisten Betriebssystemen.