What is AMQP 0-9-1 Model ?

AMQP 0-9-1이란 무엇일까요?

AMQP 0-9-1(Advanced Message Queuing Protocol)은 적합한 클라이언트 응용 프로그램이 적합한 메시징 미들웨어 브로커와 통신할 수 있도록 하는 메시징 프로토콜입니다.

메시지 브로커와 그들의 역할

메시지 브로커는 게시자(생산자라고도 하는 메시지를 게시하는 응용 프로그램) 로부터 메시지를 수신하여 소비자(이를 처리하는 응용 프로그램)에게 전달합니다.

• 네트워크 프로토콜이기 때문에 게시자, 소비자 및 브로커는 모두 다른 시스템에 상주 가능합니다.

왜 사용할까요?

일반적으로 클라이언트-서버 구조에서는 사용자가 요청을 하면 서버는 그에 대한 처리를 한 후 클라이언트에게 응답을 합니다. 간단한 서버 구조에서는 메시지큐를 사용할 필요가 없지만. 오래 걸리는 작업 (ex : 임시 비밀번호 재발급, 블로그 포스팅 등) 들을 비동기적으로 처리가 가능합니다. 클라이언트는 서버의 작업을 기다릴 필요가 없어지는 장점을 가지게 됩니다.

AMQP 0-9-1 간략한 모델

 

1. 발행자가 메시지를 RabbitMQ로 보내게 됩니다.
2. 익스체인지는 바인딩이라는 규칙을 사용하여 메시지 복사본을 큐에 배포합니다.
3. 큐를 구독하고 있는 소비자에게 메시지를 전달하거나 소비자가 필요에 따라 큐에서 메시지를 가져옵니다.
4. 메시지가 소비자에게 전달되면 소비자는 자동으로 또는 개발자의 설정에 따라 브로커에게 알립니다.
5. 메시지 승인을 사용중인 경우 알림을 수신할 때만 대기열에서 메시지를 완전히 제거합니다.

 

교환 및 교환 유형

익스체인지는 메시지가 전송되는 AMQP 0-9-1 엔티티입니다. 익스체인지는 메시지를 받아 0개 이상의 대기열로 라우팅합니다. 사용되는 라우팅 알고리즘은 교환 유형 및 바인딩 규칙에 따라 다릅니다. AMQP 0-9-1 브로커는 4가지 교환 유형을 제공합니다.

교환 유형

 

미리 선언된 기본 이름

 

Direct exchange	amq.direct
Fanout exchange	amq.fanout
Topic exchange	amq.topic
Headers exchange	amq.match

익스체인지 유형 외에도 익스체인지는 여러 속성으로 선언되며 그 중 가장 중요한 속성은 다음과 같습니다.

• 이름
• 내구성(거래소는 브로커 재시작 후에도 유지됨)
• 자동 삭제(마지막 큐가 바인딩 해제되면 교환이 삭제됨)
• 인수(선택 사항, 플로그인 및 브로커 별 기능에서 사용)

익스체인지는 영구적이거나 일시적일 수 있습니다. 내구성 있는 익스체인지는 브로커 재시작 후에도 유지되지만 임시 익스체인지는 그렇지 않습니다.

 

Direct exchange

직접 교환은 메시지 라우팅 키를 기반으로 큐에 메시지를 전달합니다. 직접 교환은 메시지 유니캐스트 라우팅이 이상적입니다. 멀티캐스트 라우팅에도 사용할 수 있습니다.

작동방식

• 큐는 라우팅 키 K를 사용하여 익스체인지에 바인딩 됩니다.
• 라우팅 키 R이 있는 새 메시지가 익스체인지에 도착하면 익스체인지는 K = R 인 경우 메시지를 큐에 라우팅합니다.
• 여러 큐가 동일한 라우팅 키 K를 사용하여 직접 교환에 바인딩된 경우 익스체인지는 K - R인 모든 대기열에 라우팅합니다.
   

Fanout exchange

팬아웃 교환은 바인딩된 모든 큐로 메시지를 라우팅하며 라우팅 키는 무시됩니다. N개의 큐에 팬아웃 교환이 바인딩 된 경우 새 메시지가 해당 교환에 게시될 때 메시지 복사본이 모든 N 대기열에 전달됩니다. 팬아웃 교환은 메시지의 브로드캐스트 라우팅에 이상적입니다.

 

Topic exchange

주제 교환은 메시지 라우팅 키와 큐를 익스체인지에서 바인딩하는데 사용된 패턴 간의 일치를 기반으로 하나 이상의 큐로 메시지를 라우팅합니다. 토픽 교환은 일반적으로 메시지의 멀티캐스트 라우팅에 사용됩니다.

 

Headers exchange

헤더 교환은 라우팅 키보다 메시지 헤더로 더 쉽게 표현되는 여러 속성에 대한 라우팅을 위해 설계되었습니다. 헤더 교환은 라우팅키 속성을 무시합니다. 대신 라우팅에 사용되는 속성은 headers 속성에서 가져옵니다. 헤더값이 바인딩 시 지정된 값과 같으면 메시지가 일치하는 것으로 간주합니다.

 

큐(대기열)

AMQP 0-9-1 모델의 대기열은 다른 메시지 및 작업 대기열 시스템의 대기열과 매우 유사합니다. 즉 애플리케이션에서 사용하는 메시지를 저장합니다. 대기열은 exchange와 일부 속성을 공유하지만 몇 가지 추가 속성이 있습니다.

• 이름
• 지속성(대기열은 브로커 재시작 후에도 유지됨)
• 배타적(하나의 연결에서만 사용되며 해당 연결이 닫히면 대기열에서 삭제됨)
• 자동 삭제(마지막 소비자가 구독을 취소하면 하나 이상의 소비자가 있는 대기열이 삭제됨)
• 인수(선택 사항, 메시지 TTL, 대기열 길이 제한 등과 같은 브로커 별 기능 및 플러그인에서 사용)

바인딩

바인딩은 메시지를 대기열로 라우팅하기 위해 익스체인지에서 사용하는 규칙입니다. 익스체인지 E가 큐 Q로 메시지를 라우팅하도록 지시하려면 Q가 E에 바인딩 되어야 합니다. 바인딩에는 일부 교환 유형에서 사용되는 선택적 라우팅 키 속성이 있을 수 있습니다. 라우팅 키의 목적은 교환에 게시된 특정 메시지를 바인딩 된 대기열로 라우팅되도록 선택하는 것입니다. 즉, 라우팅 키는 필터처럼 작용합니다.

소비자

대기열에서 메시지를 저장하는 것은 애플리케이션이 메시지를 소비할 수 없다면 쓸모가 없습니다. AMQP 0-9-1 모델에는 애플리케이션이 이를 수행하는 두가지 방법이 있습니다.

• 메시지가 전달되도록 구독(푸시 API) : 권장 옵션입니다.
• 폴링(폴 api) : 이 방법은 매우 비효율적이며 대부분 경우 피해야 합니다.

 

메시지 확인

소비자는 때때로 개별 메시지를 처리하지 못하거나 서버 연결이 끊기거나 다른 여러가지 방법으로 실패할 수 있습니다. 언제 브로커가 대기열에서 메시지를 제거해야하는지 제어 가능합니다. 두 가지 승인 모드가 있습니다.

• 브로커가 응용 프로그램에 메시지를 보낸 후 (basic.deliver 또는 basic.get-ok 메서드 사용)
• 응용 프로그램이 확인을 다시 보낸 후(basic.ack 메서드 사용)

전자를 자동 승인 모델, 후자를 명시적 승인 모델이라고 합니다. 명시적 모델을 사용하면 애플리케이션이 승인을 보낼 시간을 선택합니다. 메시지를 수신한 직후, 매시지를 완전히 처리한 후 일 수 있습니다.

 

소비자가 승인을 보내지 않고 죽으면 브로커는 이를 다른 소비자에게 다시 전달하거나, 당시 사용 가능한 소비자가 없으면 브로커는 재전달을 시도하기 전에 동일한 대기열에 적어도 한 명의 소비자가 등록될 때까지 기다립니다.

메시지 거부

소비자는 메시지를 수신하면 해당 메시지 처리가 성공할 수도 실패할 수도 있습니다. 소비자는 메시지를 거부하여 메시지 처리가 실패했음을 브로커에 알릴 수 있습니다. 메시지를 거부할 때 소비자는 브로커에게 메시지를 버리거나 다시 대기열에 추가하도록 요청 가능합니다. 대기열에 소비자가 한명 뿐인 경우 동일한 소비자의 메시지를 거부하고 다시 대기열에 넣어 무한 메시지 전달 루프를 만들지 않도록 합니다.

부정적인 승인

메시지는 basic.reject 메서드로 거부됩니다. 하지만 여러 메시지를 거부할 방법은 없습니다. RabbitMQ에 경우에는 basic.nack을 사용하여 여러 메시지를 거부할 수 있습니다.

 

메시지 속성 및 페이로드

AMQP 0-9-1 모델의 메시지에는 속성이 있습니다. 몇 가지 예는 다음과 같습니다.

• Content type
• Content encoding
• Routing key
• Delivery mode (persistent or not)
• Message priority
• Message publishing timestamp
• Expiration period
• Publisher application id

메시지는 영구적으로 게시되어 브로커가 메시지를 디스크에 유지할 수 있습니다. 서버가 다시 시작되면 시스템은 수신된 지속 메시지가 손실되지 않도록 합니다. 메시지를 지속적으로 게시하면 성능에 영향을 미칩니다.

AMQP 0-9-1이란 무엇일까요?

AMQP 0-9-1(Advanced Message Queuing Protocol)은 적합한 클라이언트 응용 프로그램이 적합한 메시징 미들웨어 브로커와 통신할 수 있도록 하는 메시징 프로토콜입니다.

메시지 브로커와 그들의 역할

메시지 브로커는 게시자(생산자라고도 하는 메시지를 게시하는 응용 프로그램) 로부터 메시지를 수신하여 소비자(이를 처리하는 응용 프로그램)에게 전달합니다.

• 네트워크 프로토콜이기 때문에 게시자, 소비자 및 브로커는 모두 다른 시스템에 상주 가능합니다.

왜 사용할까요?

일반적으로 클라이언트-서버 구조에서는 사용자가 요청을 하면 서버는 그에 대한 처리를 한 후 클라이언트에게 응답을 합니다. 간단한 서버 구조에서는 메시지큐를 사용할 필요가 없지만. 오래 걸리는 작업 (ex : 임시 비밀번호 재발급, 블로그 포스팅 등) 들을 비동기적으로 처리가 가능합니다. 클라이언트는 서버의 작업을 기다릴 필요가 없어지는 장점을 가지게 됩니다.

AMQP 0-9-1 간략한 모델

 

1. 발행자가 메시지를 RabbitMQ로 보내게 됩니다.
2. 익스체인지는 바인딩이라는 규칙을 사용하여 메시지 복사본을 큐에 배포합니다.
3. 큐를 구독하고 있는 소비자에게 메시지를 전달하거나 소비자가 필요에 따라 큐에서 메시지를 가져옵니다.
4. 메시지가 소비자에게 전달되면 소비자는 자동으로 또는 개발자의 설정에 따라 브로커에게 알립니다.
5. 메시지 승인을 사용중인 경우 알림을 수신할 때만 대기열에서 메시지를 완전히 제거합니다.

 

교환 및 교환 유형

익스체인지는 메시지가 전송되는 AMQP 0-9-1 엔티티입니다. 익스체인지는 메시지를 받아 0개 이상의 대기열로 라우팅합니다. 사용되는 라우팅 알고리즘은 교환 유형 및 바인딩 규칙에 따라 다릅니다. AMQP 0-9-1 브로커는 4가지 교환 유형을 제공합니다.

교환 유형

 

미리 선언된 기본 이름

 

Direct exchange	amq.direct
Fanout exchange	amq.fanout
Topic exchange	amq.topic
Headers exchange	amq.match

익스체인지 유형 외에도 익스체인지는 여러 속성으로 선언되며 그 중 가장 중요한 속성은 다음과 같습니다.

• 이름
• 내구성(거래소는 브로커 재시작 후에도 유지됨)
• 자동 삭제(마지막 큐가 바인딩 해제되면 교환이 삭제됨)
• 인수(선택 사항, 플로그인 및 브로커 별 기능에서 사용)

익스체인지는 영구적이거나 일시적일 수 있습니다. 내구성 있는 익스체인지는 브로커 재시작 후에도 유지되지만 임시 익스체인지는 그렇지 않습니다.

 

Direct exchange

직접 교환은 메시지 라우팅 키를 기반으로 큐에 메시지를 전달합니다. 직접 교환은 메시지 유니캐스트 라우팅이 이상적입니다. 멀티캐스트 라우팅에도 사용할 수 있습니다.

작동방식

• 큐는 라우팅 키 K를 사용하여 익스체인지에 바인딩 됩니다.
• 라우팅 키 R이 있는 새 메시지가 익스체인지에 도착하면 익스체인지는 K = R 인 경우 메시지를 큐에 라우팅합니다.
• 여러 큐가 동일한 라우팅 키 K를 사용하여 직접 교환에 바인딩된 경우 익스체인지는 K - R인 모든 대기열에 라우팅합니다.
   

Fanout exchange

팬아웃 교환은 바인딩된 모든 큐로 메시지를 라우팅하며 라우팅 키는 무시됩니다. N개의 큐에 팬아웃 교환이 바인딩 된 경우 새 메시지가 해당 교환에 게시될 때 메시지 복사본이 모든 N 대기열에 전달됩니다. 팬아웃 교환은 메시지의 브로드캐스트 라우팅에 이상적입니다.

 

 

Topic exchange

주제 교환은 메시지 라우팅 키와 큐를 익스체인지에서 바인딩하는데 사용된 패턴 간의 일치를 기반으로 하나 이상의 큐로 메시지를 라우팅합니다. 토픽 교환은 일반적으로 메시지의 멀티캐스트 라우팅에 사용됩니다.

 

Headers exchange

헤더 교환은 라우팅 키보다 메시지 헤더로 더 쉽게 표현되는 여러 속성에 대한 라우팅을 위해 설계되었습니다. 헤더 교환은 라우팅키 속성을 무시합니다. 대신 라우팅에 사용되는 속성은 headers 속성에서 가져옵니다. 헤더값이 바인딩 시 지정된 값과 같으면 메시지가 일치하는 것으로 간주합니다.

 

큐(대기열)

AMQP 0-9-1 모델의 대기열은 다른 메시지 및 작업 대기열 시스템의 대기열과 매우 유사합니다. 즉 애플리케이션에서 사용하는 메시지를 저장합니다. 대기열은 exchange와 일부 속성을 공유하지만 몇 가지 추가 속성이 있습니다.

• 이름
• 지속성(대기열은 브로커 재시작 후에도 유지됨)
• 배타적(하나의 연결에서만 사용되며 해당 연결이 닫히면 대기열에서 삭제됨)
• 자동 삭제(마지막 소비자가 구독을 취소하면 하나 이상의 소비자가 있는 대기열이 삭제됨)
• 인수(선택 사항, 메시지 TTL, 대기열 길이 제한 등과 같은 브로커 별 기능 및 플러그인에서 사용)

바인딩

바인딩은 메시지를 대기열로 라우팅하기 위해 익스체인지에서 사용하는 규칙입니다. 익스체인지 E가 큐 Q로 메시지를 라우팅하도록 지시하려면 Q가 E에 바인딩 되어야 합니다. 바인딩에는 일부 교환 유형에서 사용되는 선택적 라우팅 키 속성이 있을 수 있습니다. 라우팅 키의 목적은 교환에 게시된 특정 메시지를 바인딩 된 대기열로 라우팅되도록 선택하는 것입니다. 즉, 라우팅 키는 필터처럼 작용합니다.

소비자

대기열에서 메시지를 저장하는 것은 애플리케이션이 메시지를 소비할 수 없다면 쓸모가 없습니다. AMQP 0-9-1 모델에는 애플리케이션이 이를 수행하는 두가지 방법이 있습니다.

• 메시지가 전달되도록 구독(푸시 API) : 권장 옵션입니다.
• 폴링(폴 api) : 이 방법은 매우 비효율적이며 대부분 경우 피해야 합니다.

 

메시지 확인

소비자는 때때로 개별 메시지를 처리하지 못하거나 서버 연결이 끊기거나 다른 여러가지 방법으로 실패할 수 있습니다. 언제 브로커가 대기열에서 메시지를 제거해야하는지 제어 가능합니다. 두 가지 승인 모드가 있습니다.

• 브로커가 응용 프로그램에 메시지를 보낸 후 (basic.deliver 또는 basic.get-ok 메서드 사용)
• 응용 프로그램이 확인을 다시 보낸 후(basic.ack 메서드 사용)

전자를 자동 승인 모델, 후자를 명시적 승인 모델이라고 합니다. 명시적 모델을 사용하면 애플리케이션이 승인을 보낼 시간을 선택합니다. 메시지를 수신한 직후, 매시지를 완전히 처리한 후 일 수 있습니다.

 

소비자가 승인을 보내지 않고 죽으면 브로커는 이를 다른 소비자에게 다시 전달하거나, 당시 사용 가능한 소비자가 없으면 브로커는 재전달을 시도하기 전에 동일한 대기열에 적어도 한 명의 소비자가 등록될 때까지 기다립니다.

메시지 거부

소비자는 메시지를 수신하면 해당 메시지 처리가 성공할 수도 실패할 수도 있습니다. 소비자는 메시지를 거부하여 메시지 처리가 실패했음을 브로커에 알릴 수 있습니다. 메시지를 거부할 때 소비자는 브로커에게 메시지를 버리거나 다시 대기열에 추가하도록 요청 가능합니다. 대기열에 소비자가 한명 뿐인 경우 동일한 소비자의 메시지를 거부하고 다시 대기열에 넣어 무한 메시지 전달 루프를 만들지 않도록 합니다.

부정적인 승인

메시지는 basic.reject 메서드로 거부됩니다. 하지만 여러 메시지를 거부할 방법은 없습니다. RabbitMQ에 경우에는 basic.nack을 사용하여 여러 메시지를 거부할 수 있습니다.

 

메시지 속성 및 페이로드

AMQP 0-9-1 모델의 메시지에는 속성이 있습니다. 몇 가지 예는 다음과 같습니다.

• Content type
• Content encoding
• Routing key
• Delivery mode (persistent or not)
• Message priority
• Message publishing timestamp
• Expiration period
• Publisher application id

메시지는 영구적으로 게시되어 브로커가 메시지를 디스크에 유지할 수 있습니다. 서버가 다시 시작되면 시스템은 수신된 지속 메시지가 손실되지 않도록 합니다. 메시지를 지속적으로 게시하면 성능에 영향을 미칩니다.

AMQP 0-9-1이란 무엇일까요?

AMQP 0-9-1(Advanced Message Queuing Protocol)은 적합한 클라이언트 응용 프로그램이 적합한 메시징 미들웨어 브로커와 통신할 수 있도록 하는 메시징 프로토콜입니다.

메시지 브로커와 그들의 역할

메시지 브로커는 게시자(생산자라고도 하는 메시지를 게시하는 응용 프로그램) 로부터 메시지를 수신하여 소비자(이를 처리하는 응용 프로그램)에게 전달합니다.

• 네트워크 프로토콜이기 때문에 게시자, 소비자 및 브로커는 모두 다른 시스템에 상주 가능합니다.

왜 사용할까요?

일반적으로 클라이언트-서버 구조에서는 사용자가 요청을 하면 서버는 그에 대한 처리를 한 후 클라이언트에게 응답을 합니다. 간단한 서버 구조에서는 메시지큐를 사용할 필요가 없지만. 오래 걸리는 작업 (ex : 임시 비밀번호 재발급, 블로그 포스팅 등) 들을 비동기적으로 처리가 가능합니다. 클라이언트는 서버의 작업을 기다릴 필요가 없어지는 장점을 가지게 됩니다.

AMQP 0-9-1 간략한 모델

 

1. 발행자가 메시지를 RabbitMQ로 보내게 됩니다.
2. 익스체인지는 바인딩이라는 규칙을 사용하여 메시지 복사본을 큐에 배포합니다.
3. 큐를 구독하고 있는 소비자에게 메시지를 전달하거나 소비자가 필요에 따라 큐에서 메시지를 가져옵니다.
4. 메시지가 소비자에게 전달되면 소비자는 자동으로 또는 개발자의 설정에 따라 브로커에게 알립니다.
5. 메시지 승인을 사용중인 경우 알림을 수신할 때만 대기열에서 메시지를 완전히 제거합니다.

 

교환 및 교환 유형

익스체인지는 메시지가 전송되는 AMQP 0-9-1 엔티티입니다. 익스체인지는 메시지를 받아 0개 이상의 대기열로 라우팅합니다. 사용되는 라우팅 알고리즘은 교환 유형 및 바인딩 규칙에 따라 다릅니다. AMQP 0-9-1 브로커는 4가지 교환 유형을 제공합니다.

교환 유형

 

미리 선언된 기본 이름

 

Direct exchange	amq.direct
Fanout exchange	amq.fanout
Topic exchange	amq.topic
Headers exchange	amq.match

익스체인지 유형 외에도 익스체인지는 여러 속성으로 선언되며 그 중 가장 중요한 속성은 다음과 같습니다.

• 이름
• 내구성(거래소는 브로커 재시작 후에도 유지됨)
• 자동 삭제(마지막 큐가 바인딩 해제되면 교환이 삭제됨)
• 인수(선택 사항, 플로그인 및 브로커 별 기능에서 사용)

익스체인지는 영구적이거나 일시적일 수 있습니다. 내구성 있는 익스체인지는 브로커 재시작 후에도 유지되지만 임시 익스체인지는 그렇지 않습니다.

 

Direct exchange

직접 교환은 메시지 라우팅 키를 기반으로 큐에 메시지를 전달합니다. 직접 교환은 메시지 유니캐스트 라우팅이 이상적입니다. 멀티캐스트 라우팅에도 사용할 수 있습니다.

작동방식

• 큐는 라우팅 키 K를 사용하여 익스체인지에 바인딩 됩니다.
• 라우팅 키 R이 있는 새 메시지가 익스체인지에 도착하면 익스체인지는 K = R 인 경우 메시지를 큐에 라우팅합니다.
• 여러 큐가 동일한 라우팅 키 K를 사용하여 직접 교환에 바인딩된 경우 익스체인지는 K - R인 모든 대기열에 라우팅합니다.
•  

 

Fanout exchange

팬아웃 교환은 바인딩된 모든 큐로 메시지를 라우팅하며 라우팅 키는 무시됩니다. N개의 큐에 팬아웃 교환이 바인딩 된 경우 새 메시지가 해당 교환에 게시될 때 메시지 복사본이 모든 N 대기열에 전달됩니다. 팬아웃 교환은 메시지의 브로드캐스트 라우팅에 이상적입니다.

 

 

Topic exchange

주제 교환은 메시지 라우팅 키와 큐를 익스체인지에서 바인딩하는데 사용된 패턴 간의 일치를 기반으로 하나 이상의 큐로 메시지를 라우팅합니다. 토픽 교환은 일반적으로 메시지의 멀티캐스트 라우팅에 사용됩니다.

 

Headers exchange

헤더 교환은 라우팅 키보다 메시지 헤더로 더 쉽게 표현되는 여러 속성에 대한 라우팅을 위해 설계되었습니다. 헤더 교환은 라우팅키 속성을 무시합니다. 대신 라우팅에 사용되는 속성은 headers 속성에서 가져옵니다. 헤더값이 바인딩 시 지정된 값과 같으면 메시지가 일치하는 것으로 간주합니다.

 

큐(대기열)

AMQP 0-9-1 모델의 대기열은 다른 메시지 및 작업 대기열 시스템의 대기열과 매우 유사합니다. 즉 애플리케이션에서 사용하는 메시지를 저장합니다. 대기열은 exchange와 일부 속성을 공유하지만 몇 가지 추가 속성이 있습니다.

• 이름
• 지속성(대기열은 브로커 재시작 후에도 유지됨)
• 배타적(하나의 연결에서만 사용되며 해당 연결이 닫히면 대기열에서 삭제됨)
• 자동 삭제(마지막 소비자가 구독을 취소하면 하나 이상의 소비자가 있는 대기열이 삭제됨)
• 인수(선택 사항, 메시지 TTL, 대기열 길이 제한 등과 같은 브로커 별 기능 및 플러그인에서 사용)

바인딩

바인딩은 메시지를 대기열로 라우팅하기 위해 익스체인지에서 사용하는 규칙입니다. 익스체인지 E가 큐 Q로 메시지를 라우팅하도록 지시하려면 Q가 E에 바인딩 되어야 합니다. 바인딩에는 일부 교환 유형에서 사용되는 선택적 라우팅 키 속성이 있을 수 있습니다. 라우팅 키의 목적은 교환에 게시된 특정 메시지를 바인딩 된 대기열로 라우팅되도록 선택하는 것입니다. 즉, 라우팅 키는 필터처럼 작용합니다.

소비자

대기열에서 메시지를 저장하는 것은 애플리케이션이 메시지를 소비할 수 없다면 쓸모가 없습니다. AMQP 0-9-1 모델에는 애플리케이션이 이를 수행하는 두가지 방법이 있습니다.

• 메시지가 전달되도록 구독(푸시 API) : 권장 옵션입니다.
• 폴링(폴 api) : 이 방법은 매우 비효율적이며 대부분 경우 피해야 합니다.

 

메시지 확인

소비자는 때때로 개별 메시지를 처리하지 못하거나 서버 연결이 끊기거나 다른 여러가지 방법으로 실패할 수 있습니다. 언제 브로커가 대기열에서 메시지를 제거해야하는지 제어 가능합니다. 두 가지 승인 모드가 있습니다.

• 브로커가 응용 프로그램에 메시지를 보낸 후 (basic.deliver 또는 basic.get-ok 메서드 사용)
• 응용 프로그램이 확인을 다시 보낸 후(basic.ack 메서드 사용)

전자를 자동 승인 모델, 후자를 명시적 승인 모델이라고 합니다. 명시적 모델을 사용하면 애플리케이션이 승인을 보낼 시간을 선택합니다. 메시지를 수신한 직후, 매시지를 완전히 처리한 후 일 수 있습니다.

 

소비자가 승인을 보내지 않고 죽으면 브로커는 이를 다른 소비자에게 다시 전달하거나, 당시 사용 가능한 소비자가 없으면 브로커는 재전달을 시도하기 전에 동일한 대기열에 적어도 한 명의 소비자가 등록될 때까지 기다립니다.

메시지 거부

소비자는 메시지를 수신하면 해당 메시지 처리가 성공할 수도 실패할 수도 있습니다. 소비자는 메시지를 거부하여 메시지 처리가 실패했음을 브로커에 알릴 수 있습니다. 메시지를 거부할 때 소비자는 브로커에게 메시지를 버리거나 다시 대기열에 추가하도록 요청 가능합니다. 대기열에 소비자가 한명 뿐인 경우 동일한 소비자의 메시지를 거부하고 다시 대기열에 넣어 무한 메시지 전달 루프를 만들지 않도록 합니다.

부정적인 승인

메시지는 basic.reject 메서드로 거부됩니다. 하지만 여러 메시지를 거부할 방법은 없습니다. RabbitMQ에 경우에는 basic.nack을 사용하여 여러 메시지를 거부할 수 있습니다.

 

메시지 속성 및 페이로드

AMQP 0-9-1 모델의 메시지에는 속성이 있습니다. 몇 가지 예는 다음과 같습니다.

• Content type
• Content encoding
• Routing key
• Delivery mode (persistent or not)
• Message priority
• Message publishing timestamp
• Expiration period
• Publisher application id

메시지는 영구적으로 게시되어 브로커가 메시지를 디스크에 유지할 수 있습니다. 서버가 다시 시작되면 시스템은 수신된 지속 메시지가 손실되지 않도록 합니다. 메시지를 지속적으로 게시하면 성능에 영향을 미칩니다.

 

이 게시글은 RabbitMQ 공식 문서를 참고하여 작성되었습니다.

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

AMQP 0-9-1 Model Explained — RabbitMQ