Тут добре корисне розуміння того, що робить протокол AMQP "під капотом". Я б запропонував, що документація та API, які AMQP 0.9.1 обрав для розгортання, роблять це особливо заплутаним, тому саме питання є таким, з яким багатьом людям доводиться боротися.
TL; DR
З'єднання є фізичним переговорами TCP сокета з сервером AMQP. Належно реалізовані клієнти матимуть один із них на додаток, безпечний для потоків, доступний між потоками.
Канал є один сеанс додатки на зв'язку. У потоці буде один або більше таких сеансів. AMQP архітектура 0.9.1 полягає в тому, що їх не слід ділити між потоками, і їх слід закрити / знищити, коли нитка, яка її створила, закінчиться з нею. Вони також закриваються сервером, коли трапляються різні порушення протоколу.
Споживач є віртуальною конструкцію , яка представляє наявність «поштову скриньку» на певному каналі. Використання споживача повідомляє брокеру проштовхувати повідомлення з певної черги до кінцевої точки каналу.
Факти підключення
По-перше, як правильно вказали інші, з'єднання - це об'єкт, який представляє фактичне TCP-з'єднання з сервером. Підключення визначаються на рівні протоколу в AMQP, і все спілкування з брокером відбувається через одне або більше з'єднань.
- Оскільки це фактичне TCP-з'єднання, у нього є IP-адреса та порт №.
- Параметри протоколу узгоджуються на основі клієнта як частина налаштування з'єднання (процес, відомий як рукостискання .
- Він призначений для довгожиття ; мало випадків, коли закриття з'єднання є частиною проекту протоколу.
- З точки зору OSI, він, ймовірно, знаходиться десь близько 6 рівня
- Серцебиття можна налаштувати для контролю стану з'єднання, оскільки TCP не містить нічого саме по собі для цього.
- Найкраще мати спеціальний потік, який керує зчитуванням і записом у базовий сокет TCP. Більшість, якщо не всі, клієнти RabbitMQ роблять це. У зв'язку з цим вони, як правило, безпечні для ниток.
- По відношенню, з'єднання "дорого" створити (завдяки рукостисканню), але практично кажучи, це насправді не має значення. Для більшості процесів дійсно знадобиться лише один об’єкт з'єднання. Але ви можете підтримувати з'єднання в пулі, якщо вам здається, що вам потрібна більша пропускна здатність, ніж може забезпечити один потік / розетка (малоймовірно при сучасній обчислювальній технології).
Факти каналу
Канал є додатком сеансу , який відкритий для кожної частини вашого застосування , щоб спілкуватися з RabbitMQ брокером. Він працює над одним з'єднанням і представляє сеанс з брокером.
- Оскільки він представляє логічну частину логіки програми, кожен канал зазвичай існує у власному потоці.
- Зазвичай усі канали, відкриті вашим додатком, матимуть спільне з'єднання (це легкі сеанси, які працюють над версією з'єднання). З'єднання захищені потоком, тому це нормально.
- Більшість операцій AMQP відбувається по каналах.
- З точки зору рівня OSI, канали, ймовірно, є навколо рівня 7 .
- Канали розраховані на тимчасові ; частина дизайну AMQP полягає в тому, що канал, як правило, закритий у відповідь на помилку (наприклад, повторне оголошення черги з різними параметрами перед видаленням існуючої черги).
- Оскільки вони є тимчасовими, ваші програми не повинні об'єднувати канали.
- Сервер використовує ціле число для ідентифікації каналу. Коли потік, що керує з'єднанням, отримує пакет для певного каналу, він використовує це число, щоб повідомити брокеру, якому каналу / сесії належить пакет.
- Як правило, канали не є безпечними для потоків, оскільки не має сенсу ділитися ними між потоками. Якщо у вас є інший потік, який потребує використання брокера, потрібен новий канал.
Факти споживачів
Споживач - це об'єкт, визначений протоколом AMQP. Це ні канал, ні з'єднання, а натомість те, що ваша конкретна програма використовує як "поштову скриньку" для видалення повідомлень.
- "Створення споживача" означає, що ви повідомляєте брокеру (використовуючи канал через з'єднання ), що ви хочете, щоб повідомлення, що надсилаються вам по цьому каналу. У відповідь брокер зареєструє, що у вас є споживач на каналі, і почне надсилати вам повідомлення.
- Кожне повідомлення, натиснуте на з'єднання, посилається як на номер каналу, так і на номер споживача . Таким чином, потік управління зв’язком (в даному випадку в рамках Java API) знає, що робити з повідомленням; Тоді потік обробки каналів також знає, що робити з повідомленням.
- Реалізація споживачів має найбільшу кількість варіацій, тому що це буквально залежно від застосування. У моєму виконанні я вирішив виконувати завдання щоразу, коли повідомлення надходило через споживача; таким чином, у мене був потік, що керує з'єднанням, потік, що управляє каналом (і розширенням, споживачем), і один або більше потоків завдань для кожного повідомлення, доставленого через споживача.
- Закриття з'єднання закриває всі канали з'єднання. Закриття каналу закриває всіх споживачів каналу. Також можливо скасувати споживача (без закриття каналу). Існують різні випадки, коли є сенс робити будь-яку з трьох речей.
- Як правило, реалізація споживача в клієнті AMQP виділяє споживачеві один виділений канал, щоб уникнути конфліктів з діяльністю інших потоків або коду (включаючи публікацію).
З точки зору того, що ви маєте на увазі під пулом потоків споживачів, я підозрюю, що клієнт Java робить щось подібне до того, що я запрограмував, щоб мій клієнт (мій був заснований на клієнті .Net, але сильно модифікований).
