2022 04 20 - RabbitMQ

 

• 송신자: 메시지를 전송한다.
• 큐: 대기열. 큰 메시지 버퍼라고 생각하자.
• 소비자: 메시지를 수신하기위해 대기한다.(그렇지만, 논블로킹이다.)

 

가장 간단한 구조 - 송신자와 수신자가 1:1

RabbitMQ는 메시지를 큐로 직접 보낼수 없다. 항상 exhange를 거쳐야 한다.

routing_key 는 큐의 이름이다.

메시지를 비동기적으로 푸시하기 때문에, 큐는 리스너가 메시지를 팝하기 전까지 메시지를 버퍼링한다. 

리스너는 큐를 리스닝하고 있다가 메시지가 도착하면 등록한 콜백을 동작시켜서 로직을 실행한다.

 

송신측

0)연결생성

1)큐 설정 (큐가 없으면 큐생성)

2)메시지 전송

 

수신측

0)연결생성

1)큐 설정 (큐가 없으면 큐생성)

2)메시지 처리할 콜백함수 선언

2)큐 리스닝

 

작업 대기열 생성 - 송신자 1에 수신자 다수

시간이 많이 걸리는 작업을 수신자들에게 분산이 가능하다.

 

메시지 확인

만약 워커가 로직 실행중에 죽으면? 이전까지의 로직은 메시지가 손실된다..

메시지가 손실되지 않도록 RabbitMQ는 TCP처럼 ack를 지원한다.

만약 소비자가 ack로 응답하지 않고 죽으면 RabbitMQ는 다시 큐에 넣는다.

 

이전까지는 RabbitMQ가 자동으로 ack를 보냈지만 사용자(개발자)가 로직이 정상적으로 끝난후에 ack를 보내도록 수정하자.

 

만약 중간에 오류가 생겨서 ack를 못보내면 송신자가 큐에 다시 전달한다.

 

반대로 RabbitMQ 서버가 죽으면 어떨까? 큐와 메시지를 잊어버린다.

이를 방지하기 위해 큐를 생성할때 durable = true를 설정한다. *기존 대기열은 재정의가 불가하다.

publish시에 messageProperties를 persistant_text_plain으로 메시지를 영속성으로 전송한다.

 

이제 서버가 재시작된다 하더라도 큐가 손상되지 않는다.