RabbitMQ와 채널과 연결의 관계

RabbitMQ와 채널과 연결의 관계

---

RabbitMQ 자바 클라이언트는 다음과 같은 개념이 있습니다 :

• Connection -RabbitMQ 서버 인스턴스에 대한 연결
• Channel -???
• 소비자 스레드 풀-RabbitMQ 서버 큐에서 메시지를 소비하는 스레드 풀
• 큐-FIFO 순서로 메시지를 보유하는 구조

나는 관계를 이해하기 위해 노력하고있어 더 중요한과 의 연관성 그들 사이.

1. 나는 Channel이것이 당신이 게시하고 소비하는 구조이며 개방 된 연결에서 생성된다는 사실을 제외하고는 무엇인지 확실하지 않습니다 . 누군가가 "채널"이 무엇을 나타내는 지 설명 할 수 있다면 몇 가지를 정리하는 데 도움이 될 수 있습니다.
2. 채널과 큐의 관계는 무엇입니까? 동일한 채널을 사용하여 여러 큐와 통신 할 수 있습니까, 아니면 1 : 1이어야합니까?
3. 큐와 소비자 풀의 관계는 무엇입니까? 여러 소비자를 동일한 대기열에 가입 할 수 있습니까? 동일한 소비자가 여러 대기열을 사용할 수 있습니까? 아니면 관계가 1 : 1입니까?

도움을 주셔서 감사합니다.

---

1. A Connection는 메시지 브로커에 대한 실제 TCP 연결을 나타내며 a Channel는 내부의 가상 연결 (AMQP 연결)입니다. 이 방법으로 TCP 연결로 브로커를 오버로드하지 않고도 애플리케이션 내부에서 원하는만큼 (가상) 연결을 사용할 수 있습니다.

2. Channel모든 것을 위해 하나 를 사용할 수 있습니다 . 그러나 스레드가 여러 개인 경우 Channel각 스레드마다 다른 스레드 를 사용하는 것이 좋습니다 .

   Java 클라이언트 API 안내서의 채널 스레드 안전성 :

   채널 인스턴스는 여러 스레드에서 안전하게 사용할 수 있습니다. 채널에 대한 요청은 직렬화되며 한 번에 하나의 스레드 만 채널에서 명령을 실행할 수 있습니다. 그럼에도 불구하고 응용 프로그램은 여러 스레드에서 동일한 채널을 공유하는 대신 스레드 당 채널을 사용하는 것을 선호해야합니다.

   사이에 직접적인 관계가 없다 Channel하고 Queue. A Channel는 AMQP 명령을 브로커로 보내는 데 사용됩니다. 이것은 대기열 또는 이와 유사한 생성 일 수 있지만 이러한 개념은 서로 연결되어 있지 않습니다.

3. 각각 Consumer은 소비자 스레드 풀에서 할당 된 자체 스레드에서 실행됩니다. 여러 소비자가 동일한 대기열에 가입 한 경우 브로커는 라운드 로빈을 사용하여 메시지를 동일하게 분산시킵니다. 학습서 2 : "작업 큐"를 참조하십시오 .

   Consumer여러 대기열에 동일 하게 연결할 수도 있습니다 . 소비자를 콜백으로 이해할 수 있습니다. 소비자가 바인드 된 큐에 메시지가 도착할 때마다 호출됩니다. Java 클라이언트의 경우 각 소비자는 handleDelivery(...)콜백 메소드를 나타내는 method를 갖습니다 . 일반적으로 서브 클래스 DefaultConsumer및 재정의를 수행 handleDelivery(...)합니다. 참고 : 동일한 Consumer 인스턴스를 여러 큐에 연결하면이 메소드는 다른 스레드에 의해 호출됩니다. 필요한 경우 동기화를 관리하십시오.

---

AMQP 프로토콜이 "후드에서"수행하는 작업에 대한 개념적인 이해가 여기에 유용합니다. AMQP 0.9.1이 배포하기로 선택한 문서와 API가 특히 혼란스러워서 많은 사람들이 씨름해야 할 문제입니다.

TL; DR

연결 AMQP 서버와 물리적 협상 TCP 소켓입니다. 올바르게 구현 된 클라이언트는 애플리케이션별로 스레드 안전하고 스레드간에 공유 할 수있는 애플리케이션 당 하나를 갖습니다.

채널 연결에 단일 애플리케이션 세션입니다. 스레드에는 이러한 세션 중 하나 이상이 있습니다. AMQP 아키텍처 0.9.1은 스레드간에 공유되지 않아야하며 스레드를 작성한 스레드가 완료되면 닫히거나 파기되어야한다는 것입니다. 또한 다양한 프로토콜 위반이 발생할 때 서버에 의해 닫힙니다.

소비자는 특정 채널의 "메일 박스"의 존재를 나타내는 가상 구조이다. 소비자를 사용하면 브로커에게 특정 큐에서 해당 채널 끝점으로 메시지를 푸시하도록 지시합니다.

연결 사실

첫째, 다른 사람들이 올바르게 지적했듯이 연결 은 서버에 대한 실제 TCP 연결을 나타내는 객체입니다. 연결은 AMQP의 프로토콜 수준에서 지정되며 브로커와의 모든 통신은 하나 이상의 연결을 통해 이루어집니다.

• 실제 TCP 연결이므로 IP 주소와 포트 번호가 있습니다.
• 프로토콜 매개 변수는 연결 설정 ( 핸드 셰이크 라고 알려진 프로세스)의 일부로 클라이언트별로 협상됩니다 .
• 오래 지속 되도록 설계되었습니다 . 연결 클로저가 프로토콜 디자인의 일부인 경우는 거의 없습니다.
• OSI 관점에서 보면 아마도 레이어 6 주위에있을 것입니다
• TCP에는이 작업을 수행하기위한 내용이 포함되어 있지 않으므로 연결 상태를 모니터링하도록 하트 비트를 설정할 수 있습니다.
• 전용 스레드가 기본 TCP 소켓에 대한 읽기 및 쓰기를 관리하도록하는 것이 가장 좋습니다. 전부는 아니지만 대부분 RabbitMQ 클라이언트가이를 수행합니다. 이와 관련하여 일반적으로 스레드 안전합니다.
• 상대적으로 말하면, 연결은 핸드 셰이크로 인해 "비용이 많이 들지만"실제로는 중요하지 않습니다. 대부분의 프로세스에는 실제로 하나의 연결 개체 만 필요합니다. 그러나 단일 스레드 / 소켓이 제공 할 수있는 것보다 더 많은 처리량이 필요한 경우 (현재 컴퓨팅 기술과 달리) 풀에서 연결을 유지할 수 있습니다.

채널 정보

A Channel is the application session that is opened for each piece of your app to communicate with the RabbitMQ broker. It operates over a single connection, and represents a session with the broker.

• As it represents a logical part of application logic, each channel usually exists on its own thread.
• Typically, all channels opened by your app will share a single connection (they are lightweight sessions that operate on top of the connection). Connections are thread-safe, so this is OK.
• Most AMQP operations take place over channels.
• From an OSI Layer perspective, channels are probably around Layer 7.
• Channels are designed to be transient; part of the design of AMQP is that the channel is typically closed in response to an error (e.g. re-declaring a queue with different parameters before deleting the existing queue).
• Since they are transient, channels should not be pooled by your app.
• The server uses an integer to identify a channel. When the thread managing the connection receives a packet for a particular channel, it uses this number to tell the broker which channel/session the packet belongs to.
• Channels are not generally thread-safe as it would make no sense to share them among threads. If you have another thread that needs to use the broker, a new channel is needed.

Consumer Facts

A consumer is an object defined by the AMQP protocol. It is neither a channel nor a connection, instead being something that your particular application uses as a "mailbox" of sorts to drop messages.

• "Creating a consumer" means that you tell the broker (using a channel via a connection) that you would like messages pushed to you over that channel. In response, the broker will register that you have a consumer on the channel and begin pushing messages to you.
• Each message pushed over the connection will reference both a channel number and a consumer number. In that way, the connection-managing thread (in this case, within the Java API) knows what to do with the message; then, the channel-handling thread also knows what to do with the message.
• Consumer implementation has the widest amount of variation, because it's literally application-specific. In my implementation, I chose to spin off a task each time a message arrived via the consumer; thus, I had a thread managing the connection, a thread managing the channel (and by extension, the consumer), and one or more task threads for each message delivered via the consumer.
• Closing a connection closes all channels on the connection. Closing a channel closes all consumers on the channel. It is also possible to cancel a consumer (without closing the channel). There are various cases when it makes sense to do any of the three things.
• Typically, the implementation of a consumer in an AMQP client will allocate one dedicated channel to the consumer to avoid conflicts with the activities of other threads or code (including publishing).

In terms of what you mean by consumer thread pool, I suspect that Java client is doing something similar to what I programmed my client to do (mine was based off the .Net client, but heavily modified).

---

I found this article which explains all aspects of the AMQP model, of which, channel is one. I found it very helpful in rounding out my understanding

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

Some applications need multiple connections to an AMQP broker. However, it is undesirable to keep many TCP connections open at the same time because doing so consumes system resources and makes it more difficult to configure firewalls. AMQP 0-9-1 connections are multiplexed with channels that can be thought of as "lightweight connections that share a single TCP connection".

For applications that use multiple threads/processes for processing, it is very common to open a new channel per thread/process and not share channels between them.

Communication on a particular channel is completely separate from communication on another channel, therefore every AMQP method also carries a channel number that clients use to figure out which channel the method is for (and thus, which event handler needs to be invoked, for example).

참고URL : https://stackoverflow.com/questions/18418936/rabbitmq-and-relationship-between-channel-and-connection