Rabbitmq — должно ли многопоточное приложение использовать один или несколько каналов

В моем приложении есть несколько потоков, которые публикуют сообщения в одном кластере RabbitMQ.
Чтение документов по кролику: я прочитал следующее:

Для приложений, использующих несколько потоков/процессов для обработки, очень часто открывается новый канал для каждого потока/процесса, а не совместное использование каналов между ними.

И я понимаю, что вместо того, чтобы открывать несколько соединений (дорого)
, лучше открывать несколько каналов.

Но почему бы не использовать один канал для всех потоков?
Каковы преимущества использования нескольких каналов вместо одного?


rabbitmq channel
person Bick    schedule 09.03.2014    source источник
comment
Этот общий канал будет общим ресурсом и потребует, чтобы вы гарантировали, что только один поток за раз использует эти ресурсы, что может резко повлиять на производительность многопоточности (если не сделать ее полностью спорной).   -  person Peter Ritchie    schedule 09.03.2014

Ответы (1)


arrow_upward
3
arrow_downward

AMQP использует концепцию Channel для обеспечения большей гибкости по сравнению с надежными TCP-соединениями. Открытие TCP-соединения для каждого сообщения было бы чрезвычайно дорого, поэтому они придумали идею логических Channel внутри соединения.

Не рекомендуется использовать Channel для всех потоков, потому что, если что-то выйдет из строя в конкретном потоке и Channel умрет, остальные потоки вызовут исключение AlreadyClosedException. Канал может умереть по нескольким причинам: например, из-за попытки объявить то, что уже объявлено с другими параметрами, или попытки отменить несуществующего потребителя, публикации на несуществующем обмене и т. д.

Моим лучшим советом было бы иметь объект, который содержит Channel в локальной переменной, а также реализует интерфейс ShutdownListener, поэтому каждый раз, когда канал выходит из строя, он может восстанавливаться и создавать новый из соединения. Так что я бы сказал, что главное преимущество — отказоустойчивость и масштабируемость, поскольку смерть Channel не повлияет на остальные.

person hveiga    schedule 09.03.2014