RabbitMQ und Beziehung zwischen Kanal und Verbindung

Den RabbitMQ-Java-client hat die folgenden Konzepte:

  • Connection - eine Verbindung zu einem RabbitMQ-server-Instanz
  • Channel - ???
  • Verbraucher-thread-pool - ein pool von threads, die das konsumieren von Nachrichten aus den RabbitMQ server-Warteschlangen
  • Queue - Struktur, die enthält Nachrichten in FIFO-Reihenfolge

Ich versuche zu verstehen, die Beziehung, und noch wichtigerdie Verbände zwischen Ihnen.

  1. Bin ich mir noch nicht ganz sicher, was für eine Channel ist, außer der Tatsache, dass dies die Struktur, die Sie veröffentlichen und konsumieren aus, und es entsteht eine offene Verbindung. Wenn jemand könnte mir erklären, was der "Kanal" stellt, könnte es helfen, klar ein paar Dinge.
  2. Was ist die Beziehung zwischen Kanal und die Warteschlange? Kann der gleiche Kanal verwendet werden, um die Kommunikation um ein Vielfaches Warteschlangen, oder muss es 1:1?
  3. Was ist die Beziehung zwischen Queue und der Verbraucher Pool? Können mehrere Verbraucher abonniert werden, um die gleiche Warteschlange? Können mehrere Queues konsumiert werden, die von den gleichen Verbraucher? Oder ist das Verhältnis 1:1?

Vielen Dank im Voraus für jede Hilfe hier!

InformationsquelleAutor der Frage | 2013-08-24

  1. 130

    1. Einen Connection stellt eine echte TCP Verbindung zum message-broker, in der Erwägung, dass eine Channel ist eine virtuelle Verbindung (AMPQ Verbindung) drin. Auf diese Weise können Sie so viele (virtuelle) verbindungen, wie Sie wollen, in Ihrer Anwendung ohne überlastung der broker mit TCP-verbindungen.

    2. Können Sie eine Channel für alles. Jedoch, wenn Sie mehrere threads, es ist vorgeschlagen, die Verwendung einer anderen Channel für jeden thread.

      Kanal, thread-Sicherheit in der Java-Client-API-Handbuch:

      Kanal-Instanzen sind sicher für die Verwendung durch mehrere threads. Anfragen in
      ein Kanal serialisiert werden, mit nur einem thread laufen zu können ein
      Befehl auf dem Kanal zu einem Zeitpunkt. Auch so, die Applikationen sollten lieber
      mit ein-Kanal-pro-thread anstelle des Teilens der gleichen Kanal über
      mehrere threads.

      Gibt es keine direkte Beziehung zwischen Channel und Queue. Ein Channel senden AMQP-Befehle an den Makler. Dies kann die Erstellung einer Warteschlange oder ähnlichen, aber diese Konzepte sind nicht miteinander verbunden.

    3. Jeder Consumer läuft in einem eigenen thread zugeordnet, die in der consumer-thread-pool. Wenn mehrere Verbraucher abonniert sind, die gleiche Schlange, der broker verwendet round-robin-Verteilung der Nachrichten zwischen Ihnen ebenso. Sehen Tutorial zwei: "Work Queues".

      Ist es auch möglich, befestigen Sie die gleichen Consumer an mehrere Warteschlangen.
      Können Sie verstehen Verbraucher als callbacks. Diese sind aufgerufen, jedes mal wenn eine Nachricht in einer Warteschlange eintreffen der Verbraucher gebunden ist. Für den Fall, dass der Java-Client, jeder Verbraucher hat eine Methode handleDelivery(...) stellt für die callback-Methode. Was Sie normalerweise tun, ist, Unterklasse DefaultConsumer und überschreiben handleDelivery(...). Hinweis: Wenn Sie legen die gleichen Consumer-Instanz auf mehrere Warteschlangen haben, wird diese Methode aufgerufen werden, die von verschiedenen threads. So kümmern sich um die Synchronisation, wenn notwendig.

    InformationsquelleAutor der Antwort Bengt

  2. 18

    Fand ich diesen Artikel, der erklärt alle Aspekte der AMQP-Modell, von welcher Kanal ist. Ich fand es sehr hilfreich, abgerundet wird mein Verständnis

    https://www.rabbitmq.com/tutorials/amqp-concepts.html

    Einige Anwendungen benötigen mehrere verbindungen zu einem AMQP-broker. Es ist jedoch unerwünscht, halten viele TCP-verbindungen gleichzeitig geöffnet werden, da dadurch verbraucht Systemressourcen und macht es schwieriger zu konfigurieren firewalls. AMQP 0-9-1-verbindungen gemultiplext mit den Kanälen, die gedacht werden kann, wie "leicht verbindungen, die über eine einzelne TCP-Verbindung".

    Für Anwendungen, die mehrere threads/Prozesse, die für die Verarbeitung, ist es sehr üblich, öffnen einen neuen Kanal pro thread/Prozess und nicht die Kanäle zwischen Ihnen.

    Kommunikation auf einem Kanal völlig getrennt von der Kommunikation auf einen anderen Kanal, daher ist jede AMQP-Methode trägt auch eine Kanal-Nummer, die clients verwenden, um herauszufinden, welcher Kanal der Methode ist (und damit, welchen event-handler aufgerufen werden muß, zum Beispiel).

    InformationsquelleAutor der Antwort CamW

  3. 10

    Ein gutes konzeptionelles Verständnis von dem, was das AMQP-Protokoll "unter der Haube" ist hier nützlich. Ich würde anbieten, dass die Dokumentation und API, die AMQP 0.9.1 wählte bereitstellen, macht diese besonders verwirrend, so dass die Frage selbst ist eine, die viele Menschen haben zu Ringen.

    TL;DR

    Einen Verbindung wird die körperliche ausgehandelt TCP-socket mit dem AMQP-server. Richtig umgesetzt, erhalten die Kunden eine dieser pro-Anwendung, thread-sichere, teilbare zwischen threads.

    Einen Kanal ist eine einzelne Anwendung, die Sitzung auf die Verbindung. Ein thread wird eine oder mehrere dieser Sitzungen. AMQP-Architektur 0.9.1 ist, dass diese nicht geteilt werden zwischen threads, und sollte geschlossen werden/zerstört, wenn der thread, der erstellt wird, werden mit ihm fertig. Sie sind auch durch den server beendet wurde, wenn verschiedene Protokoll-Verletzungen auftreten.

    Einen Verbraucher ist ein virtuelles Konstrukt, stellt die Anwesenheit von einem "Postfach" auf einem bestimmten Kanal. Die Nutzung durch einen Endverbraucher, erzählt der broker auf push-Nachrichten aus einer bestimmten Warteschlange, um das channel endpoint.

    Verbindung Tatsachen

    Erste, wie andere schon richtig hingewiesen, Verbindung ist das Objekt, das stellt die eigentliche TCP-Verbindung zum server. Verbindungen, angegeben sind auf der Protokoll-Ebene im AMQP, und alle Kommunikation mit dem broker erfolgt über einen oder mehrere Anschlüsse.

    • Da es einen tatsächlichen TCP-Verbindung, es hat eine IP-Adresse und Port #.
    • Protokoll-Parameter ausgehandelt werden, die auf einer pro-client-basis als Teil der Einrichtung der Verbindung (einen Prozess bekannt als die handshake.
    • Es ist entworfen, um langlebigen; es gibt nur wenige Fälle, wo die Verbindung Schließung ist Teil des Protokoll-design.
    • Aus OSI-Sicht, es liegt wahrscheinlich irgendwo um Ebene 6
    • Herzschläge können so eingerichtet werden, überwachen Sie den status der Verbindung, da TCP nicht alles enthalten, was an und für sich, dies zu tun.
    • Ist es am besten, einen dedizierten thread zu verwalten, liest und schreibt die zugrunde liegende TCP-socket. Die meisten, wenn nicht alle, RabbitMQ clients dies tun. In dieser Hinsicht sind Sie in der Regel thread-safe.
    • Relativ gesehen-verbindungen sind "teuer" zu erstellen (aufgrund des Handshakes), aber praktisch gesprochen, dies ist eigentlich egal. Die meisten Prozesse, die wirklich brauchen nur ein connection-Objekt. Aber, Sie pflegen die verbindungen in einem pool, wenn Sie feststellen, Sie brauchen mehr Durchsatz als ein einzelnes Gewinde/socket aufnehmen kann (unwahrscheinlich, mit aktuellen it-Technologie).

    Kanal Tatsachen

    Einen Kanal ist die Anwendung die Sitzung, die geöffnet wird, für jedes Stück Ihre app für die Kommunikation mit dem RabbitMQ-broker. Es arbeitet über eine einzelne Verbindungund stellt eine Sitzung mit dem broker.

    • Wie es ist ein logischer Teil der Anwendungslogik, die jedem Kanal in der Regel vorhanden ist, auf seinen eigenen thread.
    • Normalerweise werden alle Kanäle geöffnet, die von Ihrem app wird eine einzelne Verbindung freigeben (Sie sind sehr leicht, Sitzungen, arbeiten auf der Oberseite der Verbindung). Verbindungen sind thread-sicher, so ist das OK.
    • Meisten AMQP-Operationen erfolgen über Kanäle.
    • Von einem OSI-Schicht-Perspektive, Kanäle sind wahrscheinlich um Schicht 7.
    • Kanäle sind entworfen, um vorübergehende; Teil des Entwurfs von AMQP ist, dass der Kanal normalerweise geschlossen ist, in Reaktion auf einen Fehler (z.B. re-deklarieren einer Warteschlange mit verschiedenen Parametern vor dem löschen die vorhandenen Warteschlange).
    • Da Sie vergänglich sind, Kanäle sollten nicht gepoolt werden, die von Ihrer app.
    • Verwendet der server eine ganze Zahl zur Identifizierung eines Kanals. Wenn der thread die Verwaltung der Verbindung erhält man ein Paket nach einem bestimmten channel, verwendet diese Nummer, zu sagen, der Makler, welcher Kanal/session packet gehört.
    • Kanäle sind im Allgemeinen nicht thread-sicher, da würde es keinen Sinn machen, zu teilen Sie Sie zwischen threads. Wenn Sie einem anderen thread, dass muss der broker, ein neuer Kanal erforderlich ist.

    Verbraucher-Fakten

    Einen Verbraucher wird ein Objekt definiert durch das AMQP-Protokoll. Es ist weder ein Kanal noch eine Verbindung, anstatt etwas, das Sie für Ihre bestimmte Anwendung verwendet werden, als "mailbox" Art drop-Nachrichten.

    • "Creating a consumer" bedeutet, dass Sie sagen, der broker (mit einem Kanal via Verbindung), dass Sie gerne Nachrichten geschoben, um Sie über diesen Kanal. In Reaktion, der broker registrieren, dass Sie eine Verbraucher auf den Kanal und beginnen schieben-Nachrichten an Sie.
    • Jede Nachricht gestoßen, die über die Verbindung und verweisen sowohl eine Kanalnummer und ein Verbraucher Anzahl. In dieser Weise wird die Verbindung-Verwaltung der Threads (in diesem Fall, in der Java-API) weiß, was zu tun mit der Nachricht; dann werden die Kanal-Handhabung thread auch weiß, was zu tun mit der Nachricht.
    • Verbraucher-Implementierung hat die größte Menge an variation, denn es ist buchstäblich Anwendungs-spezifisch. In meiner Umsetzung, ich entschied mich für die Ausgliederung einer Aufgabe jedes mal, wenn eine Nachricht kam über den Verbraucher; so hatte ich eine thread-Verwaltung der Verbindung, eine thread-Verwaltung des Kanals (und durch die Erweiterung der Verbraucher), und eine oder mehrere task-threads für jede übermittelte Nachricht über den Verbraucher.
    • Schließen Verbindung schließt alle Kanäle auf die Verbindung. Schließen Kanal schließt alle Verbraucher auf den Kanal. Es ist auch möglich Abbrechen Verbraucher (ohne schließen des Kanals). Es gibt verschiedene Fälle, wenn es Sinn macht, um einen der drei Dinge.
    • In der Regel, die Umsetzung von einem Verbraucher in einer AMQP-client zuweisen eines dedizierten Kanals für den Verbraucher, um Konflikte zu vermeiden, die mit den Aktivitäten von anderen threads oder code (einschließlich Verlage).

    In Bezug auf das, was du meinst, von Verbraucher-thread-pool, ich vermute, dass Java-client der etwas ähnliches macht, was ich programmiert habe, meinen Mandanten zu tun (mir wurde auf der Grundlage der .Net-client, aber stark modifiziert).

    InformationsquelleAutor der Antwort theMayer

Schreibe einen Kommentar