RabbitMQ i relacja między kanałem a połączeniem

Znalazłem ten artykuł, który wyjaśnia wszystkie aspekty modelu AMQP, z których kanał jest jeden. Uważam, że jest to bardzo pomocne w zaokrągleniu mojego zrozumienia

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

Niektóre aplikacje wymagają wielu połączeń z brokerem AMQP. Jednak nie jest pożądane utrzymywanie wielu połączeń TCP otwartych w tym samym czasie, ponieważ zużywa to zasoby systemowe i utrudnia konfigurację zapór sieciowych. AMQP 0-9-1 połączenia są multipleksowane z kanałami, które można traktować jako "lekkie połączenia, które dzielą jedno połączenie TCP".

W przypadku aplikacji, które używają wielu wątków / procesów do przetwarzania, bardzo często otwiera się nowy kanał dla każdego wątku / procesu, a nie współdzielenie kanałów między nimi.

Komunikacja na danym kanale jest całkowicie oddzielona od komunikacji na innym kanale, dlatego każda metoda AMQP niesie również numer kanału, który klient Użyj, aby dowiedzieć się, do którego kanału jest przeznaczona metoda(i w ten sposób, na przykład, która obsługa zdarzeń musi być wywołana).

Dobre rozumienie tego, co protokół AMQP robi "pod maską" jest tutaj przydatne. Chciałbym zaoferować, że dokumentacja i API, które AMQP 0.9.1 zdecydował się wdrożyć, czyni to szczególnie mylące, więc samo pytanie Jest Takie, z którym wiele osób musi się zmagać.

TL; DR

A połączenie jest fizycznym negocjowanym gniazdem TCP z serwerem AMQP. Odpowiednio zaimplementowani klienci będą mieli jeden z nich na aplikację, bezpieczny dla wątku, udostępnialny wśród wątków.

A Kanał jest pojedynczą sesją aplikacji na połączeniu. Wątek będzie miał jedną lub więcej z tych sesji. Architektura AMQP 0.9.1 polega na tym, że nie mają one być dzielone między wątki i powinny być zamknięte/zniszczone, gdy wątek, który je utworzył, zostanie z nim zakończony. Są one również zamykane przez serwer, gdy występują różne naruszenia protokołu.

A consumer jest wirtualnym konstruktem, który reprezentuje obecność "skrzynki pocztowej" na konkretnym kanał. Korzystanie z konsumenta mówi brokerowi, aby wypychał wiadomości z określonej kolejki do punktu końcowego kanału.

Connection Facts

Po pierwsze, jak inni poprawnie wskazali, Połączenie jest obiektem, który reprezentuje rzeczywiste połączenie TCP z serwerem. Połączenia są określone na poziomie protokołu w AMQP, a cała komunikacja z brokerem odbywa się przez jedno lub więcej połączeń.

• ponieważ jest to rzeczywiste połączenie TCP, to posiada adres IP i Port #.
[27]} parametry protokołu są negocjowane na podstawie klienta jako część konfiguracji połączenia (proces znany jako handshake.
• jest zaprojektowany tak, aby był długotrwały ; jest kilka przypadków, w których zamknięcie połączenia jest częścią projektu protokołu.
Z punktu widzenia OSI prawdopodobnie znajduje się gdzieś w okolicach warstwy 6.]}
• Heartbeats można skonfigurować do monitorowania stanu połączenia, ponieważ TCP nie zawierać w sobie wszystko, aby to zrobić.
• najlepiej mieć dedykowany wątek zarządzający odczytami i zapisami do bazowego gniazda TCP. Większość, jeśli nie wszystkie, RabbitMQ klientów to zrobić. Pod tym względem są one na ogół bezpieczne dla wątków.
• relatywnie mówiąc, połączenia są" drogie " w tworzeniu (ze względu na uścisk dłoni), ale praktycznie rzecz biorąc, to naprawdę nie ma znaczenia. Większość procesów tak naprawdę potrzebuje tylko jednego obiektu połączenia. Ale, można utrzymać połączenia w basenie, jeśli potrzebujesz większej przepustowości, niż może zapewnić pojedynczy wątek/Gniazdo (mało prawdopodobne przy obecnej technologii obliczeniowej).

Fakty Kanału

A Kanał jest sesją aplikacji, która jest otwierana dla każdego kawałka Twojej aplikacji do komunikacji z brokerem RabbitMQ. Działa przez pojedyncze połączenie i reprezentuje sesję z brokerem.

• ponieważ reprezentuje logiczną część logiki aplikacji, każdy kanał Zwykle istnieje na własnym wątku.
• zazwyczaj wszystkie kanały otwarte przez aplikację będą współdzielić jedno połączenie (są to lekkie sesje, które działają na szczycie połączenia). Połączenia są bezpieczne dla wątków, więc jest OK.
• większość operacji AMQP odbywa się za pośrednictwem kanałów.
• z perspektywy warstwy OSI kanały są prawdopodobnie wokół warstwy 7 .
• kanały są zaprojektowane tak, aby były przejściowe ; część konstrukcji AMQP polega na tym, że kanał jest zazwyczaj zamykane w odpowiedzi na błąd (np. ponowne deklarowanie kolejki z różnymi parametrami przed usunięciem istniejącej kolejki).
• ponieważ są one przejściowe, kanały nie powinny być łączone przez aplikację.
• serwer używa liczby całkowitej do identyfikacji kanału. Gdy wątek zarządzający połączeniem otrzymuje pakiet dla określonego kanału, używa tego numeru, aby powiedzieć brokerowi, do którego kanału / sesji należy dany pakiet.
• kanały nie są generalnie bezpieczne dla wątków, ponieważ nie ma sensu dzielić się nimi między wątki. Jeśli masz inny wątek, który musi użyć brokera, potrzebny jest nowy kanał.

Fakty Konsumenckie

Konsument jest obiektem zdefiniowanym przez protokół AMQP. Nie jest to ani kanał, ani połączenie, zamiast tego jest czymś, czego dana aplikacja używa jako" skrzynki pocztowej " do upuszczania wiadomości.

• "Tworzenie konsumenta" oznacza, że mówisz brokerowi (używając kanału poprzez połączenie ), które chcesz, aby wiadomości były do ciebie przesyłane przez ten kanał. W odpowiedzi broker zarejestruje, że masz konsumenta na kanale i rozpocznie wysyłanie wiadomości do ciebie.
• każda wiadomość przepchnięta przez połączenie będzie odwoływać się zarówno do numeru kanału , jak inumeru konsumenta . W ten sposób wątek zarządzający połączeniem (w tym przypadku w Java API) wie, co zrobić z Komunikatem; następnie wątek obsługujący kanał również wie, co zrobić z wiadomością.
• implementacja konsumencka ma najszerszą zmienność, ponieważ jest dosłownie specyficzna dla aplikacji. W mojej implementacji zdecydowałem się spin off zadania za każdym razem, gdy wiadomość dotarła przez konsumenta; tak więc miałem wątek zarządzający połączeniem, wątek zarządzający kanałem (a co za tym idzie, konsumentem) i jeden lub więcej wątków zadania dla każdej wiadomości dostarczonej przez konsumenta.
• zamknięcie połączenia zamyka wszystkie kanały na połączenie. Zamknięcie kanału zamyka wszystkich konsumentów na kanale. Możliwe jest również anulowanie konsumenta (bez zamykania kanału). Istnieją różne przypadki, w których sensowne jest zrobienie którejkolwiek z tych trzech rzeczy.
• zazwyczaj implementacja konsumenta w kliencie AMQP przydziela konsumentowi jeden dedykowany kanał, aby uniknąć konfliktów z działaniami innych wątków lub kodu (w tym publikacji).

W kategoriach co masz na myśli przez consumer thread pool, podejrzewam, że Klient Javy robi coś podobnego do tego, do czego zaprogramowałem mojego klienta (mój był oparty na kliencie. Net, ale mocno zmodyfikowany).