Was sind die Alternativen zu ZeroMQ, um Protokoll-Puffer-Payloads zu verschieben?

8

Im Moment habe ich eine Lösung, die ZeroMQ zum Austausch von Protokoll-Puffer-Payloads verwendet. Die Protokollpuffermethode der Serialisierung bleibt so wie sie ist, aber ich kann ZMQ durch eine bequemere Option ersetzen. Die Dinge, über die ich in ZMQ nicht glücklich bin, sind:

Es verwendet JNI auf der Java-Seite, und ich wurde vorher von JNI in komplexen Multi-Thread-Szenarien gebissen. Ich versuche es zu eliminieren, wann immer ich kann.

Ich brauche keine Warteschlangen, ich brauche nur rpc.

Meine Anforderungen (die meistens von ZeroMQ abgedeckt werden) sind:

  • Unterstützung für 32/64 Bit * nix, Windows, MacOS.

  • Die Unterstützung für Java, C ++ und C # in erster Linie und Python, Ruby usw. wäre nett.

  • Die Sprachunterstützung muss von nativen Implementierungen in der Sprache bereitgestellt werden, nicht durch das Einbinden von nativem Code.

  • Hohe Leistung.

  • Nicht virale Lizenz, keine GPL, AGPL etc.

  • Ich habe darüber nachgedacht, Thrift als Transportschicht über TCP (ich glaube, es unterstützt dies) mit Protokollpuffern zu verwenden, wenn seine Java-Implementierung für Messaging keine JNI verwendet.

Welche Optionen können Sie sich für dieses Setup anders als ZMQ vorstellen?

    
mahonya 14.04.2012, 18:56
quelle

3 Antworten

7

Haben Sie etwas wie Storm oder Spread in Betracht gezogen? ?

    
Christopher Smith 17.04.2012, 07:28
quelle
10

Sie sollten sich wahrscheinlich Netty ansehen. Es ist ein leistungsstarkes Java NIO Server-Framework mit integrierter Unterstützung für Protocol Buffer, das unter den Bedingungen der Apache-Lizenz veröffentlicht wird. Das Framework ist gut dokumentiert und einige Beispiele zeigen, wie Protokolle mit Protokollpuffern prototypiert werden können.

    
Bertil Chapuis 15.04.2012 18:27
quelle
0
___ qstnhdr ___ Was sind die Alternativen zu ZeroMQ, um Protokoll-Puffer-Payloads zu verschieben? ___ tag123java ___ Java (nicht zu verwechseln mit JavaScript oder JScript oder JS) ist eine universelle objektorientierte Programmiersprache, die für die Verwendung in Verbindung mit der Java Virtual Machine (JVM) entwickelt wurde. "Java-Plattform" ist der Name für ein Computersystem, auf dem Tools zum Entwickeln und Ausführen von Java-Programmen installiert sind. Verwenden Sie dieses Tag für Fragen, die sich auf die Java-Programmiersprache oder Java-Plattform-Tools beziehen. ___ tag123c ___ C ++ ist eine universelle Programmiersprache. Es wurde ursprünglich als Erweiterung von C entworfen und behält eine ähnliche Syntax, ist aber jetzt eine komplett andere Sprache. Verwenden Sie dieses Tag für Fragen zu Code, der mit einem C ++ - Compiler kompiliert werden soll. ___ answer10186979 ___

Haben Sie etwas wie Storm oder Spread in Betracht gezogen? ?

    
___ tag123rpc ___ Remote Procedure Call (RPC) ist ein Ansatz für die Interprozessor- oder verteilte Kommunikation, bei dem eine Reihe von Diensten oder Prozeduren für entfernte Clients verfügbar gemacht werden. RPC ist sowohl ein allgemeines Konzept für die Kommunikation zwischen Prozessoren als auch eine Abkürzung für die ursprüngliche Implementierung von Sun (im Folgenden SunRPC genannt). ___ tag123protocolbuffers ___ Protokollpuffer sind eine sprachneutrale und plattformneutrale Möglichkeit, strukturierte Daten in einem effizienten, aber erweiterbaren Format zu verschlüsseln. Google verwendet Protokollpuffer für fast alle internen RPC-Protokolle und Dateiformate. Es ist auch die Standard-Datencodierung, die vom Open-Source-Framework gRPC verwendet wird. ___ answer10164798 ___

Sie sollten sich wahrscheinlich Netty ansehen. Es ist ein leistungsstarkes Java NIO Server-Framework mit integrierter Unterstützung für Protocol Buffer, das unter den Bedingungen der Apache-Lizenz veröffentlicht wird. Das Framework ist gut dokumentiert und einige Beispiele zeigen, wie Protokolle mit Protokollpuffern prototypiert werden können.

    
___ tag123zeromq ___ ZeroMQ (ZMQ, 0MQ, ØMQ) ist eine hochperformante, asynchrone Transportklassen-Agnostic-Messaging-Bibliothek für den Einsatz in skalierbaren, verteilten und / oder konkurrierenden Anwendungen. Es stellt eine Nachrichtenwarteschlange bereit, aber im Gegensatz zur nachrichtenorientierten Middleware kann ein ZeroMQ-System ohne dedizierten Nachrichtenbroker ausgeführt werden. Lizenz: LGPL mit Ausnahme für statische Verknüpfung ___ antwort43815068 ___

Die ursprüngliche Frage wurde ungefähr ein Jahr nach dem JeroMQ gestellt, das auf github gestellt wurde. Es ist die pure-Java-Implementierung von ZeroMQ. Es hat sich in den vergangenen Jahren stetig weiterentwickelt und scheint der Geschwindigkeit der C-Implementierung vergleichbar zu sein . p>     

___ qstntxt ___

Im Moment habe ich eine Lösung, die ZeroMQ zum Austausch von Protokoll-Puffer-Payloads verwendet. Die Protokollpuffermethode der Serialisierung bleibt so wie sie ist, aber ich kann ZMQ durch eine bequemere Option ersetzen. Die Dinge, über die ich in ZMQ nicht glücklich bin, sind:

Es verwendet JNI auf der Java-Seite, und ich wurde vorher von JNI in komplexen Multi-Thread-Szenarien gebissen. Ich versuche es zu eliminieren, wann immer ich kann.

Ich brauche keine Warteschlangen, ich brauche nur rpc.

Meine Anforderungen (die meistens von ZeroMQ abgedeckt werden) sind:

  • Unterstützung für 32/64 Bit * nix, Windows, MacOS.

  • Die Unterstützung für Java, C ++ und C # in erster Linie und Python, Ruby usw. wäre nett.

  • Die Sprachunterstützung muss von nativen Implementierungen in der Sprache bereitgestellt werden, nicht durch das Einbinden von nativem Code.

  • Hohe Leistung.

  • Nicht virale Lizenz, keine GPL, AGPL etc.

  • Ich habe darüber nachgedacht, Thrift als Transportschicht über TCP (ich glaube, es unterstützt dies) mit Protokollpuffern zu verwenden, wenn seine Java-Implementierung für Messaging keine JNI verwendet.

Welche Optionen können Sie sich für dieses Setup anders als ZMQ vorstellen?

    
___
Johann 05.05.2017 23:30
quelle