폭간의 기술블로그 HomeArchivesTagsCategories
AMQP 0-9-1 모델 설명
|rabbitmq|

AMQP 0-9-1 모델 설명

AMQP 0-9-1은 무엇입니까?

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

브로커과 그들의 역할

메시징 브로커는 게시자 ( 게시자 라고도하는 게시 된 응용 프로그램) 로부터 메시지를 받고
소비자 (메시지를 처리하는 응용 프로그램) 에게 라우팅합니다 .

네트워크 프로토콜이므로 게시자, 소비자 및 브로커는 모두 다른 컴퓨터에 상주 할 수 있습니다.

AMQP 0-9-1 모델 요약

AMQP 0-9-1 모델은 다음과 같은 세계관을 가지고 있습니다. 메시지는 교환소 에 게시되며 종종 우체국이나 사서함과 비교됩니다.
그런 다음 Exchange 는 바인딩 이라는 규칙을 사용하여 메시지 복사본을 큐에 배포합니다.
그런 다음 브로커는 대기열에 가입 한 소비자에게 메시지를 전달하거나 소비자는 요청시 대기열에서 메시지를 가져 오거나 당깁니다.

메시지를 게시 할 때 게시자는 다양한 메시지 속성 (메시지 메타 데이터)을 지정할 수 있습니다.
이 메타 데이터 중 일부는 브로커가 사용할 수 있지만 나머지 메타 데이터는 브로커에게 완전히 불투명하며 메시지를받는 응용 프로그램에서만 사용됩니다.

네트워크를 신뢰할 수없고 응용 프로그램이 메시지를 처리하지 못할 수 있으므로 AMQP 0-9-1 모델은 메시지 승인 개념을 갖습니다.
메시지가 소비자 에게 배달되면 소비자 는 자동으로 또는 응용 프로그램 개발자가 선택하자마자 브로커 에게 알립니다.
그렇게하기 위해. 메시지 승인이 사용 중이면 브로커는 해당 메시지 (또는 메시지 그룹)에 대한 알림을 수신 할 때만 큐에서 메시지를 완전히 제거합니다.

예를 들어 메시지를 라우팅 할 수없는 특정 상황에서는 메시지가 게시자에게 반환 되거나 삭제되거나 브로커가 확장을 구현하는 경우 소위
“데드 레터 큐 (dead letter queue)”에 배치 될 수 있습니다.
게시자는 특정 매개 변수를 사용하여 메시지를 게시하여 이와 같은 상황을 처리하는 방법을 선택합니다.

큐, 교환 및 바인딩을 통칭하여 AMQP 엔티티 라고합니다 .

AMQP 0-9-1은 프로그래밍 가능한 프로토콜입니다

AMQP 0-9-1은 AMQP 0-9-1 엔터티 및 라우팅 체계가 주로 브로커 관리자가 아닌 응용 프로그램 자체에 의해 정의된다는 점에서
프로그래밍 가능한 프로토콜입니다. 따라서, 큐와 교환을 선언하고, 그들 사이의 바인딩을 정의하고,
큐를 구독하는 등의 프로토콜 작업이 제공 됩니다.

이것은 어플리케이션 개발자에게 많은 자유를 주지만 잠재적 인 정의 충돌을 인식해야합니다.
실제로 정의 충돌은 드물며 종종 잘못된 구성을 나타냅니다.

응용 프로그램은 필요한 AMQP 0-9-1 엔티티를 선언하고 필요한 라우팅 체계를 정의하며 더 이상 사용되지 않을 때
AMQP 0-9-1 엔티티를 삭제하도록 선택할 수 있습니다.

거래소 및 거래소 유형

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

  • Direct exchange : (Empty string) and amq.direct
  • Fanout exchange : amq.fanout
  • Topic exchange : amq.topic
  • Headers exchange : amq.match (and amq.headers in RabbitMQ)

교환 유형 외에도 교환은 여러 속성으로 선언되며 그 중 가장 중요한 속성은 다음과 같습니다.

  • Name
  • Durability (교환은 브로커 재시작 후에도 지속됨)
  • Auto-delete (마지막 큐가 바인딩 해제되면 교환이 삭제됨)
  • Arguments (선택 사항, 플러그인 및 브로커 별 기능에서 사용)

교환은 내구성이 있거나 일시적 일 수 있습니다. 영구 교환은 브로커 재시작 후에도
일시적인 교환은 유지되지 않습니다 (브로커가 다시 온라인 상태가되면 다시 선언해야 함).
모든 시나리오와 사용 사례에서 교환이 내구성이 필요한 것은 아닙니다.

Default Exchange

기본 교환은 브로커가 미리 선언 한 이름 (빈 문자열)이없는 직접 교환입니다.
간단한 응용 프로그램에 매우 유용한 하나의 특수 속성이 있습니다.
생성되는 모든 큐는 큐 이름과 동일한 라우팅 키를 사용하여 자동으로 바인딩됩니다.

예를 들어 이름이 “search-indexing-online”인 대기열을 선언하면
AMQP 0-9-1 브로커는 “search-indexing-online”을 라우팅 키로 사용하여 기본 교환기에 바인딩합니다
(이 경우에 따라 바인딩 키라고도 함). 따라서 라우팅 키 “search-indexing-online”을 사용하여 기본 교환에 게시 된
메시지는 큐 “search-indexing-online”으로 라우팅됩니다.
다시 말해, 기본 교환은 메시지가 기술적으로 일어나지 않더라도 대기열에 직접 메시지를 전달할 수있는 것처럼 보입니다.

Direct exchange

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

작동 방식은 다음과 같습니다.

  • 라우팅 키 K를 사용하여 큐를 교환에 바인딩
  • 라우팅 키가 R 인 새 메시지가 직접 교환에 도착하면 교환기는 K = R 인 경우이를 큐로 라우팅합니다.

직접 교환은 종종 라운드 로빈 방식으로 여러 작업자 (같은 응용 프로그램의 인스턴스)간에 작업을 배포하는 데 사용됩니다.
그렇게 할 때 AMQP 0-9-1에서 메시지는 큐간에가 아니라 소비자간에로드 밸런싱된다는 것을 이해하는 것이 중요합니다.

Fanout exchange

팬 아웃 교환은 바인딩 된 모든 큐로 메시지를 라우팅하고 라우팅 키는 무시됩니다.
N 큐가 팬 아웃 교환에 바인드되면 새 메시지가 해당 교환에 공개되면 메시지 사본이 모든 N 큐에 전달됩니다.
팬 아웃 교환은 메시지의 브로드 캐스트 라우팅에 이상적입니다.

팬 아웃 교환은 바인딩 된 모든 큐에 메시지 사본을 전달하므로 사용 사례는 매우 유사합니다.

  • 대규모 멀티 플레이어 온라인 (MMO) 게임은 리더 보드 업데이트 또는 기타 글로벌 이벤트에 사용할 수 있습니다.
  • 스포츠 뉴스 사이트는 팬 아웃 교환을 사용하여 거의 실시간으로 모바일 클라이언트에 점수 업데이트를 배포 할 수 있습니다
  • 분산 시스템은 다양한 상태 및 구성 업데이트를 브로드 캐스트 할 수 있습니다
  • 그룹 채팅은 팬 아웃 교환을 사용하여 참가자간에 메시지를 배포 할 수 있습니다
    (AMQP에는 기본 제공 개념이 없으므로 XMPP가 더 나은 선택 일 수 있음)

Topic exchange

토픽 교환은 메시지 라우팅 키와 교환을 큐에 바인드하는 데 사용 된 패턴 간의 일치를 기반으로 메시지를 하나 이상의 큐로 라우팅합니다.
토픽 교환 유형은 종종 다양한 발행 / 구독 패턴 변형을 구현하는 데 사용됩니다.
주제 교환은 일반적으로 메시지의 멀티 캐스트 라우팅에 사용됩니다.

주제 교환에는 매우 광범위한 사용 사례가 있습니다.
어떤 유형의 메시지를 받고자 하는지를 선택하는 여러 소비자 / 응용 프로그램과 관련된 문제가있을 때마다 주제 교환 사용을 고려해야합니다.

사용 예:

  • 특정 지역 (예 : 판매 지점)과 관련된 데이터 배포
  • 특정 작업 집합을 처리 할 수있는 여러 작업자가 수행 한 백그라운드 작업 처리
  • 주식 가격 업데이트 (및 다른 종류의 재무 데이터에 대한 업데이트)
  • 분류 또는 태그가 포함 된 뉴스 업데이트 (예 : 특정 스포츠 또는 팀 전용)
  • 클라우드에서 다양한 종류의 서비스 오케스트레이션
  • 각 빌더가 하나의 아키텍처 또는 OS 만 처리 할 수있는 분산 아키텍처 / OS 특정 소프트웨어 빌드 또는 패키징

Headers exchange

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

일치를 위해 둘 이상의 헤더를 사용하여 큐를 헤더 교환에 바인딩 할 수 있습니다.
이 경우 브로커는 응용 프로그램 개발자로부터 하나 이상의 정보를 필요로합니다.
즉, 헤더가 일치하는 메시지 또는 모두를 고려해야하는 메시지를 고려해야합니까?
이것이 “x-match”바인딩 인수의 목적입니다. “x-match”인수가 “any”로 설정되면 하나의 일치하는 헤더 값만으로 충분합니다.
또는 “x-match”를 “all”로 설정하면 모든 값이 일치해야합니다.

헤더 교환은 “스테로이드에 대한 직접 교환”으로 볼 수 있습니다.
헤더 값을 기준으로 라우팅하기 때문에 라우팅 키가 문자열 일 필요가없는 직접 교환으로 사용할 수 있습니다.
예를 들어 정수 또는 해시 (사전) 일 수 있습니다.

문자열 x-로 시작하는 헤더 는 일치를 평가하는 데 사용되지 않습니다.

Queues

큐 AMQP 0-9-1 모델에서 다른 메시지 - 및 작업 - 대기 시스템의 큐와 매우 유사하다
그들은 응용 프로그램에 의해 소비되는 메시지를 저장합니다.
대기열은 교환과 일부 속성을 공유하지만 추가 속성도 있습니다
  • Name
  • Durable (큐는 브로커 재시작 후에도 지속됨)
  • Exclusive (하나의 연결에서만 사용되며 해당 연결이 닫히면 대기열이 삭제됨)
  • Auto-delete (최종 소비자가 구독을 취소하면 소비자가 한 명 이상인 대기열이 삭제됨)
  • Arguments (선택 사항 : 메시지 TTL, 큐 길이 제한 등과 같은 플러그인 및 브로커 특정 기능에서 사용)

대기열을 사용하려면 먼저 선언해야합니다. 큐를 선언하면 큐가 아직 없으면 작성됩니다.
큐가 이미 존재하고 해당 속성이 선언의 속성과 동일하면 선언이 적용되지 않습니다.
기존 큐 속성이 선언의 속성과 동일하지 않으면 코드 406 ( PRECONDITION_FAILED ) 의 채널 레벨 예외 가 발생합니다.

Queues Name

애플리케이션은 큐 이름을 선택하거나 브로커에게 이름을 생성하도록 요청할 수 있습니다.
큐 이름은 최대 255 바이트의 UTF-8 문자 일 수 있습니다. AMQP 0-9-1 브로커는 앱 대신 고유 한 큐 이름을 생성 할 수 있습니다.
이 기능을 사용하려면 빈 문자열을 대기열 이름 인수로 전달하십시오. 생성 된 이름은 큐 선언 응답과 함께 클라이언트로 리턴됩니다.

“amq”로 시작하는 큐 이름 브로커가 내부 용으로 예약합니다.
이 규칙을 위반하는 이름으로 큐를 선언하려고하면 응답 코드 403 ( ACCESS_REFUSED ) 의 채널 수준 예외가 발생 합니다.

Queues Durable

영구 대기열은 디스크에 유지되므로 브로커가 다시 시작된 후에도 유지됩니다.
내구성이없는 큐를 임시라고합니다. 모든 시나리오와 사용 사례가 대기열을 내구성있게 요구하지는 않습니다.

큐의 내구성은 해당 큐로 라우팅되는 메시지 를 지속 시키지 않습니다.
브로커가 중단 된 후 다시 시작되면 브로커 시작 중에 지속 가능한 큐가 다시 선언되지만 지속성 메시지 만 복구됩니다.

Bindings

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

유추를 그리려면 :

  • 대기열은 뉴욕시의 목적지와 같습니다
  • 교환은 JFK 공항과 같습니다
  • 바인딩은 JFK에서 목적지까지의 경로입니다. 도달 할 수있는 방법이 없거나 많을 수 있습니다

이 간접 계층을 사용하면 대기열에 직접 게시를 사용하여 구현하기가 불가능하거나
매우 어려운 라우팅 시나리오를 구현할 수 있으며 특정 양의 중복 된 작업 응용 프로그램 개발자가 수행하지 않아도됩니다.

메시지를 큐에 라우트 할 수없는 경우 (예를 들어, 메시지를 발행 한 교환에 대한 바인딩이 없기 때문에)
발행자가 설정 한 메시지 속성에 따라 메시지 가 삭제되거나 발행자에게 리턴됩니다 .

Consumers

애플리케이션이 메시지를 사용할 수없는 경우 메시지를 큐에 저장하는 것은 쓸모가 없습니다.
AMQP 0-9-1 모델에는 애플리케이션이이를 수행하는 두 가지 방법이 있습니다.

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

“푸시 API”를 사용하면 응용 프로그램은 특정 큐의 메시지 소비에 관심을 가져야합니다.
그렇게 할 때 소비자 를 등록 하거나 단순히 대기열에 가입 한다고 말합니다.
대기열 당 소비자를 두 명 이상 보유하거나 배타적 소비자 를 등록 할 수 있습니다 (사용중인 대기열에서 다른 모든 소비자는 제외).

각 소비자 (구독)에는 consumer tag 라는 식별자가 있습니다. 메시지 구독을 취소하는 데 사용할 수 있습니다. 소비자 태그는 단지 문자열입니다.

Message Acknowledgements

소비자 응용 프로그램, 즉 메시지를 받고 처리하는 응용 프로그램은 때때로 개별 메시지를 처리하지 못하거나 때로는 중단 될 수 있습니다.
네트워크 문제로 인해 문제가 발생할 수도 있습니다. 브로커가 큐에서 메시지를 언제 제거해야합니까?
AMQP 0-9-1 사양은 소비자에게 이를 제어합니다.
두 가지 승인 모드가 있습니다 .

  • 브로커가 애플리케이션에 메시지를 보낸 후 ( basic.deliver 또는 basic.get-ok 메소드 사용)
  • 애플리케이션이 승인을 보낸 후 ( basic.ack 메소드 사용)

전자 선택 모델을 자동 승인 모델이라고하고 후자를 명시 적 승인 모델이라고합니다.
명시 적 모델을 사용하면 응용 프로그램은 승인을 보낼 시간을 선택합니다.
메시지를 수신 한 직후 또는 메시지를 처리하기 전에 또는 메시지를 완전히 처리 한 후
(예 : 웹 페이지를 성공적으로 가져 와서 처리하고 일부 영구 데이터 저장소에 저장) 메시지를 데이터 저장소에 지속 한 직후에있을 수 있습니다.

소비자가 승인을 보내지 않고 사망 한 경우 브로커는이를 다른 소비자에게 재전송하거나
해당 시점에 사용 가능한 것이 없으면 적어도 하나의 소비자가 동일한 대기열에 등록 될 때까지 기다렸다가 재전송을 시도합니다.

Rejecting Messages

소비자 응용 프로그램에서 메시지를 받으면 해당 메시지의 처리가 성공하거나 성공하지 못할 수 있습니다.
응용 프로그램은 메시지를 거부하여 메시지 처리가 실패했거나 당시에는 수행 할 수 없음을 브로커에 알릴 수 있습니다.
메시지를 거부하면 응용 프로그램은 브로커에게 메시지를 삭제하거나 다시 요청하도록 요청할 수 있습니다.
대기열에 소비자가 하나 뿐인 경우 동일한 소비자의 메시지를 반복해서 거부하고 다시 요청하여 무한한 메시지 전달 루프를 만들지 않도록하십시오.

Negative Acknowledgements

basic.reject 메소드를 사용하여 메시지가 거부됩니다 .
basic.reject 에는 한 가지 제한 사항이 있습니다.
승인으로 할 수있는 것처럼 여러 메시지를 거부 할 수있는 방법이 없습니다.
그러나 RabbitMQ를 사용하는 경우 해결책이 있습니다.
RabbitMQ는 부정적 승인 또는 낙관 으로 알려진 AMQP 0-9-1 확장을 제공합니다.
자세한 내용은 Confirmations 및 basic.nack 확장 설명서 를 참조하십시오 .

Prefetching Messages

여러 소비자가 대기열을 공유하는 경우 다음 승인을 보내기 전에 각 소비자가 한 번에 보낼 수있는 메시지 수를 지정할 수 있습니다.
이는 간단한로드 밸런싱 기술로 사용되거나 메시지가 배치로 게시되는 경향이있는 경우 처리량을 향상시키는 데 사용될 수 있습니다.
예를 들어, 생성하는 응용 프로그램이 수행하는 작업의 특성으로 인해 1 분마다 메시지를 보내는 경우

RabbitMQ는 연결 또는 크기 기반 프리 페칭이 아닌 채널 레벨 프리 페치 수만 지원합니다.

Message Attributes and Payload

AMQP 0-9-1 모델의 메시지에는 속성이 있습니다.
일부 속성은 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 브로커가 사용하지만 대부분은이를받는 응용 프로그램에서 해석 할 수 있습니다.
일부 속성은 선택 사항이며 헤더라고 합니다. HTTP의 X-Headers와 유사합니다. 메시지 속성은 메시지가 게시 될 때 설정됩니다.

메시지에는 또한 페이로드 ( 메시지가 가지고있는 데이터)가 있으며 AMQP 브로커는 불투명 바이트 배열로 취급합니다.
브로커는 페이로드를 검사하거나 수정하지 않습니다. 메시지는 속성 만 포함하고 페이로드는 포함하지 않을 수 있습니다.
JSON, Thrift, Protocol Buffers 및 MessagePack과 같은 직렬화 형식을 사용하여 구조화 된 데이터를 직렬화하여 메시지 페이로드로 게시하는 것이 일반적입니다.
프로토콜 피어는 일반적으로 “content-type”및 “content-encoding”필드를 사용하여이 정보를 전달하지만 이는 규칙에 의한 것입니다.

메시지가 지속성으로 발행되어 브로커가 메시지를 디스크에 지속시킬 수 있습니다.
서버가 다시 시작되면 시스템은 수신 된 지속성 메시지가 유실되지 않도록합니다.
지속 가능한 교환에 메시지를 게시하거나 라우팅 된 큐가 지속 가능하다는 사실은 메시지를 지속시키지 않습니다.
모두 메시지 자체의 지속성 모드에 따라 다릅니다.
지속성으로 메시지를 게시하면 성능에 영향을줍니다 (데이터 저장소와 마찬가지로 내구성은 특정 성능 비용이 발생 함).

게시자 안내서 에서 자세히 알아보세요 .

Message Acknowledgements

네트워크를 신뢰할 수없고 응용 프로그램이 실패하기 때문에 일종의 처리 확인이 필요합니다.
때로는 메시지가 수신되었다는 사실 만 인정하면됩니다.
때때로 승인은 소비자가 메시지를 확인하고 처리했음을 의미합니다 (예 : 필수 데이터가있는 것으로 확인되고 데이터 저장소에 지속되거나 색인화 됨).

이 상황은 매우 흔하므로 AMQP 0-9-1에는 소비자가 메시지 전달 및 / 또는 처리를 확인하는 데 사용하는 메시지 확인 (때로는 acks 라고 함) 이라는 내장 기능이 있습니다.
응용 프로그램이 충돌하는 경우 (연결이 닫힐 때 AMQP 브로커가이를 알립니다) 메시지에 대한 승인이 예상되었지만 AMQP 브로커가 수신하지 않으면
메시지가 다시 큐에 들어갑니다 (있는 경우 즉시 다른 소비자에게 전달 될 수 있음) 존재합니다).

프로토콜에 승인 기능이 내장되어 있으면 개발자가보다 강력한 소프트웨어를 구축 할 수 있습니다.

AMQP 0-9-1 방법

AMQP 0-9-1은 여러 가지 방법 으로 구성됩니다. 메소드는 (HTTP 메소드와 같은) 연산이며 객체 지향 프로그래밍 언어의 메소드와 공통점이 없습니다.
AMQP 0-9-1의 프로토콜 메소드는 클래스로 그룹화됩니다. 클래스는 AMQP 메소드의 논리적 그룹입니다.
AMQP 0-9-1 참조는 모든 AMQP 방법의 자세한 내용이 있습니다.

거래소 운영과 관련된 방법 그룹 인 거래소 클래스를 살펴 보겠습니다.
다음과 같은 작업이 포함됩니다.

  • exchange.declare
  • exchange.declare-ok
  • exchange.delete
  • exchange.delete-ok

RabbitMQ 사이트 참조에는이 가이드에서 다루지 않을 교환 클래스에 대한 RabbitMQ 관련 확장도 포함되어 있습니다.

위의 작업은 논리 쌍인 exchange.declare 및 exchange.declare-ok , exchange.delete 및 exchange.delete-ok를 형성 합니다.
이러한 작업은 “요청”(고객이 보냄) 및 “응답”(위에 언급 된 “요청”에 대한 응답으로 중개인이 보냄)입니다.

예를 들어, 클라이언트는 브로커에게 exchange.declare 메소드를 사용하여 새 교환을 선언하도록 요청합니다 .

exchange.declare 는 여러 매개 변수를 전달 합니다.
이를 통해 클라이언트는 교환 이름, 유형, 내구성 플래그 등을 지정할 수 있습니다.
작업이 성공하면 브로커는 exchange.declare-ok 메소드로 응답합니다 .

exchange.declare-ok 는 채널 번호를 제외하고 매개 변수를 전달하지 않습니다 (채널은 이 가이드의 뒷부분에서 설명).
이벤트 순서는 AMQP 0-9-1 큐 메소드 클래스 의 다른 메소드 쌍 ( queue.declare 및 queue.declare-ok) 과 매우 유사합니다 .

모든 AMQP 0-9-1 방법이 대응하는 것은 아닙니다.
일부 ( basic.publish 가 가장 널리 사용되는 방법)에는 해당 “응답” 방법이 없고 다른 일부 ( 예 : basic.get )에는 둘 이상의 가능한 “응답”이 있습니다.

Connections

AMQP 0-9-1 연결은 일반적으로 오래 지속됩니다.
AMQP 0-9-1은 안정적인 전달을 위해 TCP를 사용하는 응용 프로그램 수준 프로토콜입니다.
연결은 인증을 사용하며 TLS를 사용하여 보호 할 수 있습니다.
응용 프로그램을 더 이상 서버에 연결할 필요가 없으면 기본 TCP 연결을 갑자기 닫는 대신 AMQP 0-9-1 연결을 정상적으로 닫아야합니다.

Channels

일부 응용 프로그램은 브로커에 여러 연결이 필요합니다.
그러나 많은 TCP 연결을 동시에 열어두면 시스템 리소스가 소비되고 방화벽을 구성하기가 더 어려워 지므로 바람직하지 않습니다.
AMQP 0-9-1 연결은 “단일 TCP 연결을 공유하는 경량 연결”로 생각할 수있는 채널 과 함께 다중화됩니다 .

클라이언트가 수행하는 모든 프로토콜 작업은 채널에서 발생합니다.
특정 채널의 통신은 다른 채널의 통신과 완전히 별개이므로 모든 프로토콜 방법에는 채널 ID (일명 채널 번호)도 포함됩니다.
이 ID는 브로커와 클라이언트가 해당 방법의 채널을 파악하는 데 사용하는 정수입니다.

채널은 연결 컨텍스트에만 존재하며 절대로 존재하지 않습니다. 연결이 닫히면 모든 채널이 연결됩니다.

처리에 여러 스레드 / 프로세스를 사용하는 응용 프로그램의 경우 스레드 / 프로세스 당 새 채널을 열고 채널간에 공유하지 않는 것이 일반적입니다.

Virtual Hosts

단일 브로커가 여러 격리 된 “환경”(사용자 그룹, 교환, 대기열 등)을 호스팅 할 수 있도록
AMQP 0-9-1에는 가상 호스트 ( vhost) 개념이 포함되어 있습니다.
이들은 널리 사용되는 많은 웹 서버에서 사용하는 가상 호스트와 유사하며 AMQP 엔티티가 존재하는 완전히 격리 된 환경을 제공합니다.
프로토콜 클라이언트는 연결 협상 중에 사용할 가상 호스트를 지정합니다.

AMQP is Extensible

AMQP 0-9-1에는 몇 가지 확장 점이 있습니다.

  • 사용자 정의 교환 유형 을 사용하면 개발자는 기본 제공되는 교환 유형 (예 : 지리 데이터 기반 라우팅)에 적합하지 않은 라우팅 체계를 구현할 수 있습니다.
  • 교환 및 큐 선언에는 브로커가 사용할 수있는 추가 속성이 포함될 수 있습니다. 예를 들어 RabbitMQ의 큐당 메시지 TTL 은 이러한 방식으로 구현됩니다.
  • 프로토콜에 대한 브로커 별 확장. 예를 들어 RabbitMQ가 구현하는 확장을 참조하십시오 .
  • 새로운 AMQP 0-9-1 메소드 클래스 가 도입 될 수 있습니다.
  • 추가 플러그인을 사용 하여 브로커를 확장 할 수 있습니다. 예를 들어 RabbitMQ 관리 프론트 엔드 및 HTTP API는 플러그인으로 구현됩니다.

이러한 기능 덕분에 AMQP 0-9-1 모델은 훨씬 더 유연하고 광범위한 문제에 적용 할 수 있습니다.

AMQP 0-9-1 Clients Ecosystem

많은 인기 프로그래밍 언어와 플랫폼은 많은 AMQP 0-9-1 클라이언트가 있습니다.
그들 중 일부는 AMQP 용어를 밀접하게 따르며 AMQP 방법의 구현 만 제공합니다.
일부 다른 기능에는 추가 기능, 편리한 방법 및 추상화가 있습니다.
일부 클라이언트는 비동기식 (비 차단)이고 일부 클라이언트는 동기식 (차단)이며 일부는 두 모델을 모두 지원합니다.
일부 클라이언트는 공급 업체별 확장 (예 : RabbitMQ 관련 확장)을 지원합니다.

AMQP의 주요 목표 중 하나는 상호 운용성이므로 개발자가 프로토콜 작업을 이해하고 특정 클라이언트 라이브러리의 용어로 제한하지 않는 것이 좋습니다.
이렇게하면 다른 라이브러리를 사용하는 개발자와 의사 소통하는 것이 훨씬 쉬워집니다.

참조

rabbitmqamqp-concepts