RabbitMQ 기초

RabbitMQ는 AMQP를 구현한 오픈 소스 메시지 브로커 소프트웨어이다.
STOMP, MQTT 등의 프로토콜을 지원하기 위해 플러그인 구조와 함께 확장되고 있다.

메세지 브로커라는 것을 이해하려면 RabbitMQ에서 사용하는 용어에 대해 먼저 이해할 필요가 있다.

 

 

주요 용어

Producer

• 메세지를 전송하는 주체를 Producer라고 한다.
• 생성된 메세지는 최종적으로 특정 Queue에 넣어져야 하나 Producer는 메세지를 직접 Queue에 넣을 수 없고 Exchange만이 Queue에 메세지를 넣을 수 있다.

Consumer

• Producer로부터 메세지를 받아 처리하는 주체
• Consumer는 Queue에 직접 접근하여 메세지를 가져온다.

Exchange

• Producer로부터 전달받은 메세지를 어떤 queue로 보낼지 결정하는 장소
• 4가지 타입이 있으며 일종의 라우터 개념이라고 생각하면 된다.

Queue

• Consumer가 메세지를 consume 하기 전까지 보관하는 장소
• Queue는 이름으로 구분된다.

Binding

• Exchange와 Queue의 관계, 보통 사용자가 특정 exchange가 특정 queue를 binding하도록 정의한다.
• 보통 사용자가 특정 exchange가 특정 queue를 binding하도록 정의한다. (fanout 타입은 제외)

 

 

Data Flow

RabbitMQ의 데이터 흐름은 다음과 같다.

1. Producer는 exchange에 메세지를 게시한다.
2. Exchange는 메세지를 수신하고 메세지 라우팅을 담당한다.
3. Binding에는 반드시 Queue와 Exchange를 설정해야 한다.
4. 메세지는 Consumer가 처리할 때 까지 대기열에 남아있고 Consumer가 메세지를 처리하면 삭제된다.

 

 

Exchange의 4가지 타입

Direct	라우팅 키가 정확하게 일치하는 Queue에 메세지 전송
Topic	라우팅 키 패턴이 일치하는 Queue에 메세지 전송
Headers	[Key:Value]로 이루어진 header 값을 기준으로 일치하는 Queue에 메세지 전송
Fanout	해당 Exchange에 등록된 모든 Queue에 메세지 전송

라우팅 키는 Binding에서 쓰이는 Value라고 생각하면 된다.

 

 

Dispatching

여러 소비자가 1개의 Queue를 바라보고 있다면 RabbitMQ에서는 Round-Robin을 사용해 메세지를 균등하게 분배한다.
즉, 중복처리를 방지하기 위해 첫번째 메세지는 Cousumer1에게 전달하고 두번째 메세지는 Consumer1이 아닌 Consumer2에게 전달한다.

 

 

FairDispatching

2개의 Producer만이 존재하고 홀수번째의 메세지 크기는 항상 크고 짝수번째의 메세지 크기는 항상 작다면 Round-Robin 방식을 사용해 메세지를 분배해도 Consumer에게 공평하게 전달되지 않는다.
이러한 이유로 지연이 발생한 Consumer에는 메세지를 전달하지 않도록 prefetch count라는 개념을 사용하는데. prefetch count가 1로 설정되어 있고 Consumer로부터 act를 받지 못한 메세지가 1개라도 있으면 해당 Consumer에게 메세지를 전달하지 않는다.
즉, prefetch count는 소비자에게 동시에 전달되는 메세지의 양이다.

 

 

Message와 Queue의 보존

RabbitMQ가 종료되면 Queue와 안에 있는 메세지는 모두 제거된다.
하지만 Queue를 선언할 때 Durable 속성을 True로 설정하면 RabbitMQ가 종료된 후 다시 시작될 때 해당 Queue는 다시 자동으로 생성된다.
하지만 이렇게 해도 Queue 내부의 메세지는 여전히 삭제된다.
이를 방지하려면 Producer가 메세지를 Exchange로 보낼 때 Persistent 속성을 부여하면 된다.
그러면 메세지도 다시 생성될 것이다.

 

 

언제 쓰이는가 ?

• 요청을 많은 사용자에게 전달할 때
• 요청에 대한 처리시간이 길 때
• 많은 작업이 요청되어 처리해야 할 때
• 요청을 다른 API에 위임하고 빠른 응답을 해야할 때

 

 

 

참조

https://jithub.tistory.com/443