RabbitMQ : 교환, 대기열 및 바인딩 - 누가 설정합니까?

Question

RabbitMQ를 사용하여 메시지를 보낼 때 기본적으로 교환, 대기열 및 바인딩이 있습니다. 나는 그들의 생각과 그것들이 서로 어떻게 연관되어 있는지 이해해 왔지만 누가 무엇을 설정하는지에 대해 잘 모릅니다.

기본적으로 세 가지 시나리오가 있습니다.

시나리오 1 : 하나 개 출판사, 여러 노동자는 내가 무엇을 달성하고자하는

가 큐에 메시지를 전송 한 구성 요소이며, 해당 대기열에서 항목을 처리하는 여러 작업자 프로세스가 있어야한다 처리합니다. 이것은 나에게 아주 쉬운 것처럼 보인다. 설정은 다음과 같다 :

• 교환 : 1 큐
• 바인딩 : : 메시지가 때마다 큐는 교환

에 바인딩 '직접'

큐

유형 1 개 교환 교환기로 전송되면 대기열로 전달되고 작업자 프로세스는 자신의 작업을 가져옵니다.

모든 것이 내구성이 있어야합니다.

누가 무엇을 설정합니까? 내 의견으로는 :

• 프로듀서는
• 프로듀서 큐를 만들어 교환 생성 (현재 실행중인 작업자 프로세스가 없을 수 있으므로, 어떤 큐 없었다 경우 메시지 그렇지 않으면 손실 될 것이다)
• 프로듀서 바인딩을 수행가 교환
• 소비자의 큐의 단순히 큐

오른쪽에 들어?

시나리오 2 : 하나 개 출판사, 여러 가입자, 휘발성 메시지

두 번째 시나리오는 매우 다르다. 기본적으로, 그것은 각 메시지가 현재 청취중인 모든 클라이언트에게 보내지는 pub/sub 시나리오입니다. 클라이언트가 오프라인 상태가되면 더 이상 메시지를 수신하지 못하며 어디서나 메시지가 저장되지 않습니다. 바인딩 각 소비자

에 대한 n 개의 큐, 하나 :

• 거래소 : 형식 '팬 아웃'
• 큐 1 개 교환이 다음 설치를 의미 각각의 큐는 교환 결합 될 필요가

누가 무엇을 설정합니까?내 의견으로는 :

는

• 프로듀서는
• 소비자가 큐를 만들어 교환 생성 (이 자신의 큐와 같이하고, 생산자는 메시지에 관심이 누구든지 알 수 없다)
• 소비자에 대기열에 대한 바인딩 생성 교환
• 소비자는 큐

마우스 오른쪽 버튼을 청취?

시나리오 3 : 소비자가 오프라인이 경우 하나의 발행인, 여러 가입자, 내구성이 메시지 기본적으로

시나리오 2와 같은

하지만, 메시지가 손실되지 않아야한다. 내 의견으로는 이것은 아무것도 변경해서는 안됩니다 - 맞습니까?

Answer 1

나는 당신이 말을하는 것은 바로 시나리오 소비자가 오프라인 다음 내구성 대기열을 필요로하고 대기열이 auto_delete'd 할 수없는가는 경우 메시지가 손실되지 않아야 경우 3.

을 제외하고 생각합니다.

다른 모든 것이 나에게 맞는 것처럼 보입니다.

시나리오 2의 경우 RabbitMQ가 자동으로 대기열 이름을 생성하도록 허용 한 다음 소비자가 연결을 끊으면 대기열을 자동 삭제하도록 할 수 있습니다.