AMQP 프로토콜 소개
AMQP(Advanced Message Queuing Protocol)는 통합 메시징 서비스를 제공하는 애플리케이션 계층 표준 프로토콜로, 메시지 지향 미들웨어를 위해 설계된 애플리케이션 계층 프로토콜의 오픈 표준입니다. AMQP는 프로세스 간에 비동기 메시지를 전달하기 위한 네트워크 프로토콜입니다.
이 프로토콜을 기반으로 한 클라이언트와 메시지 미들웨어는 서로 다른 클라이언트/미들웨어 제품이나 개발 언어 등에 의해 제한받지 않고 메시지를 전달할 수 있습니다.
AMQP의 주요 특징은 메시지 지향, 대기열, 라우팅(피어 투 피어 및 게시/구독 포함), 신뢰성, 그리고 보안성입니다. AMQP는 메시지 제공자와 클라이언트의 동작을 강제하여 서로 다른 벤더 간 진정한 상호 운용성을 가능하게 합니다.
AMQP와 JMS
JMS는 초기 메시지 미들웨어를 표준화하려는 시도였지만, API 수준에서만 표준화되었고 상호운용성을 창출하기에는 거리가 멉니다.
JMS와 달리, AMQP는 네트워크를 통해 전송되는 데이터 형식을 바이트 단위로 흐르는 유선 수준 프로토콜입니다. 그 결과, 메시지를 생성하고 해석하는 이 데이터 형식을 따르는 모든 도구는 다른 호환 도구들과 상호 운용이 가능합니다.
AMQP 핵심 구성
프로듀서
제작 소식.
커넥션팩토리
커넥션을 제조하는 공장.
연결
Broker TCP/IP/Triple Handshake와 Quad Wave를 통한 애플리케이션 네트워크 연결.
AMQP 연결은 보통 긴 연결입니다. AMQP는 TCP를 사용하여 신뢰할 수 있는 전달을 제공하는 애플리케이션 계층 프로토콜입니다. AMQP는 인증 메커니즘을 사용하고 TLS(SSL) 보호를 제공합니다. 애플리케이션이 더 이상 AMQP 프록시에 연결할 필요가 없을 때, 단순히 TCP 연결을 종료하는 대신 AMQP 연결을 원활하게 해제해야 합니다.
채널
네트워크 채널은 커넥션 위에 구축된 경량 연결입니다. 거의 모든 작업은 메시지를 읽고 쓰는 채널인 채널에서 수행되며, 클라이언트는 각 채널마다 세션 작업을 나타내는 쌍을 설정할 수 있습니다.
연결을 광섬유 케이블과 비교하면, 채널 채널은 광섬유 케이블 내 섬유 중 하나와 비교됩니다. 한 커넥션에는 원하는 수의 채널을 생성할 수 있습니다.
대부분의 비즈니스 운영은 채널 인터페이스에서 이루어지며, 여기에는 다음이 포함됩니다:
- queueDeclare
- 교환 선언
- queueBind queueBind
- 메시지 게시 basicPublish
- 소비자 뉴스, basic, Consume 등.
브로커
클라이언트의 연결을 수락하여 rabbitmq와 같은 AMQP 엔티티 서비스를 구현하세요.
VirtualHost (웹 호스팅)
가상 호스팅은 논리적 격리를 위해 사용되며, 가상 호스트는 여러 개의 교환기와 큐를 가질 수 있으며, 동일한 가상 호스트가 같은 이름을 가진 교환기를 가질 수 없습니다.
단일 프록시에서 여러 고립된 환경(사용자, 사용자 그룹, 스위치, 큐 등)을 구현하기 위해 AMQP는 가상 호스트(가상 호스트 - v호스트) 개념을 제공합니다. 이는 AMQP 엔터티를 위한 완전히 격리된 환경을 제공하는 웹 서버 웹 호스팅 개념과 매우 유사합니다. 연결이 확립되면 AMQP 클라이언트는 사용할 가상 호스트를 지정합니다.
교환
스위치는 메시지를 수신하고 라우팅 키에 기반해 바운드 큐로 메시지를 전송합니다(메시지 저장 기능은 없이).
스위치는 메시지를 전송하는 데 사용되는 AMQP 엔터티입니다. 스위치가 메시지를 받으면 1개 또는 0개의 큐로 라우팅합니다. 사용하는 라우팅 알고리즘은 스위치 유형과 바인딩 규칙에 의해 결정됩니다.
스위치 종류:
스위치 특성:
- 이름: 스위치의 이름
- 내구성: 이 스위치가 지속되는지 여부를 나타내는 지속성 플래그입니다
- 자동 삭제: 삭제 플래그, 즉이 교환을 통해 모든 큐가 완료되면, 삭제 여부
- 논증: 에이전트 자체에 따라
스위치 상태:
영구 스위치는 브로커가 재시작된 후에도 존재하지만, 스테이징 스위치는 존재하지 않습니다(브로커가 다시 온라인에 들어간 후 다시 선언해야 합니다).
기본 스위치
기본 교환은 실제로 메시지 브로커가 미리 선언한 직접 교환이며, 이름이 빈 문자열입니다.
기본 스위치는 특별한 직접 연결 스위치라고 생각할 수 있습니다.
기본 스위치 이름: 널 문자열 (AMQP 기본값)
기본 스위치 유형: 직접 연결 스위치
큐를 생성할 때, 바인딩할 스위치가 지정되어 있지 않으면 자동으로 기본 스위치에 바인딩되며, 바인딩의 라우팅 키 이름은 큐 이름과 동일하게 됩니다.
스위치와의 직접 연결
직접 연결 스위치는 메시지가 전달하는 라우팅 키를 기반으로 해당 바인딩 키 큐에 메시지를 전달합니다. 직접 교환기가 메시지를 처리하는 데 사용하는 유니캐스트 라우팅입니다.
큐를 생성할 때 직접 스위치에 바인딩되어 있다면 라우팅 키의 이름을 지정할 필요가 없습니다. 기본 라우팅 키 이름이 큐 이름과 동일하기 때문입니다.
직접 연결 스위치 큐는 일반적으로 여러 소비자에게 작업을 루프 형태로 분배합니다(이를 폴링이라고 부릅니다).
워크플로우:
- 큐를 스위치에 바인딩할 때, R을 가정할 때 바인딩 키를 부여합니다;
- 라우팅 키가 포함된 메시지가 직접 연결 스위치로 전송되면, 스위치는 라우팅 키가 있는 큐로 라우팅합니다.
팬 스위치
팬 스위치는 라우팅 키와 상관없이 자신에 묶인 모든 큐에 메시지를 라우팅합니다.
N개의 큐가 섹터 스위치에 바인딩되어 있다면, 메시지가 이 섹터 스위치로 전송되면 스위치는 메시지 사본을 모든 N개 큐에 따로 전송합니다. 팬 스위치는 일반적으로 메시지의 브로드캐스트 라우팅을 처리하는 데 사용됩니다.
적용 시나리오:
방송 메시지;
단체 채팅 기능.
테마 전환
주제 전환은 라우팅 키와 교환 유형에 따라 하나 이상의 큐로 메시지를 보내며, 우리는 종종 이를 통해 다양한 게시/구독, 즉 발행 구독을 구현합니다.
직접 연결 스위치의 라우팅 규칙은 엄격히 일치하므로, 라우팅 키는 메시지를 큐로 보내기 전에 바인딩 키와 일치해야 합니다.
주제 전환의 라우팅 규칙은 와일드카드를 통해 일부 규칙을 만족함으로써 전달할 수 있는 퍼지 매치입니다.
그 내용은 다음과 같이 규정합니다:
- 퍼지 매칭을 위해 바인딩 키에 두 개의 특수 문자 * 와 #이 있을 수 있습니다. 여기서 *는 단어 #用于匹配多个单词를 맞추기 위해 사용됩니다 (0일 수 있음)
- 라우팅 키는 점으로 구분된 문자열로, 각 개별 문자열을 점 표시로 구분한 문자열을 단어라고 부릅니다
- 프로듀서가 Routing Key=A.A.A.라는 메시지를 보낼 때, A.*.*만 충족되며, 이 메시지는 오직 Queue1로만 라우팅됩니다.
- 프로듀서가 Routing Key=A.B.A 메시지를 보낼 때, A.*.*와 *.B.*가 충족되면 큐1과 큐2로 라우팅됩니다.
- 프로듀서가 Routing Key=A.B.C 메시지를 보내면, A.*.*, *.B.* 및 *.*가 만족됩니다. C는 큐1, 큐2, 큐3로 라우팅됩니다.
적용 시나리오:
- 카테고리나 태그가 포함된 뉴스 업데이트;
- 여러 명의 작업자가 수행한 배경 작업으로, 각자가 특정 작업을 담당합니다.
헤드 스위치
헤더 스위치는 라우팅 키의 일치 규칙에 의존하지 않고, 전송된 메시지 내용의 헤더 속성을 기반으로 매칭합니다.
헤드 스위치는 직접 연결 스위치의 또 다른 형태로 볼 수 있습니다. 하지만 직접 스위치의 라우팅 키는 문자열이어야 하며, 헤더 속성 값은 이에 제한받지 않고 정수나 해시 값(사전) 등일 수도 있습니다. 더 많은 유연성을 위해서(하지만 실제로는 헤드 스위치를 거의 사용하지 않습니다).
워크플로우:
- 큐가 헤더 스위치에 바인딩될 때, 매칭을 위해 여러 헤더가 동시에 바인딩됩니다.
- 수신 메시지는 헤더와 "x-match" 매개변수를 포함합니다. "x-match"가 "any"로 설정되면 헤더의 모든 값을 매칭할 수 있고, "x-match"가 "all"로 설정되면 헤더의 모든 값을 매칭해야 합니다.
스위치 요약
제본
교환기와 대기열(Queue) 간의 가상 연결.
BindingKey는 Exchange 및 Queue 바인딩에 대한 규칙 설명입니다. 바인딩 키는 현재 교환 하에서 현재 바인딩된 큐에 할당될 라우팅 키의 종류를 지정합니다.
라우팅 키
라우팅 규칙으로, 가상 머신이 특정 메시지를 라우팅하는 방법을 결정하는 데 사용할 수 있습니다.
바인딩 키 vs. 라우팅 키
- 구속 키는 큐와 스위치 사이의 구속 키이며;
- 라우팅 키는 프로듀서가 스위치로 보내는 정보 조각입니다;
- 바인딩 키와 라우팅 키가 일치할 때, 해당 큐에 메시지를 넣으세요.
바인딩 키는 Exchange 및 Queue 바인딩의 규칙 설명으로, Exchange가 메시지를 받을 때 Routing Key 필드를 가지며, Exchange는 이 라우팅 키를 현재 Exchange의 모든 바인딩 키와 일치시키고, 요구사항이 충족되면 Binding으로 전송됩니다 키는 메시지를 보내기 위해 큐에 바인딩됩니다.
다양한 스위치에서의 바인딩 키 vs. 라우팅 키
기본 스위치: 바인딩 키는 큐 이름으로, 커스터마이징할 수 없습니다. 라우팅 키는 큐 이름이기도 하며, 큐로 성공적으로 라우팅되기 전의 이름이기도 합니다
직접 연결 스위치: 바인딩 키는 큐 이름으로, 사용자 지정 가능합니다. 라우팅 키는 바인딩 키가 동일할 때만 큐로 성공적으로 라우팅될 수 있습니다
팬 스위치: 바인딩 키 없음; 물론, 라우팅 키는 없습니다. 스위치에 묶인 모든 큐로 자동으로 라우팅됨
테마 전환: 커스텀 바인딩 키; 라우팅 키를 커스터마이즈하세요. 라우팅 키==바인딩 키이며, 퍼지 매칭은 반드시 큐로 라우팅되어야 합니다
헤드 스위치: 바이딩 키 없음; 물론, 라우팅 키는 없습니다. 메시지 내용의 헤더 속성을 기반으로 매칭
큐
앱에서 곧 소비될 메시지를 저장합니다.
큐 특성:
- 이름: 대기열의 이름입니다
- 내구성: 메시지 브로커가 재시작된 후에도 큐는 여전히 존재합니다
- 독점: 한 연결에서만 사용되며, 연결이 종료되면 대기열이 삭제됩니다
- 자동 삭제: 마지막 소비자가 구독을 취소할 때 삭제됩니다
- 인수: 일부 메시지 브로커는 TTL과 유사한 추가 기능을 수행하기 위해 이를 사용합니다
큐 생성:
큐는 선언된 후에만 사용할 수 있습니다. 큐가 이미 존재하지 않는다면, 큐를 선언하면 큐가 생성됩니다. 선언된 큐가 이미 존재하고 속성이 동일하다면, 선언은 원래 큐에 영향을 미치지 않습니다. 선언의 속성이 기존 큐와 다르면, 406 오류 코드가 있는 채널 수준의 예외가 투입됩니다.
큐 지속성:
영구 큐는 디스크에 저장되며 브로커가 재시작될 때 그 자리에 남아 있습니다. 영속되지 않은 큐를 일시적 큐(transient queues)라고 합니다. 모든 시나리오와 케이스가 큐 지속성을 요구하는 것은 아닙니다.
지속된 큐는 그 큐로 라우팅된 메시지를 영구적으로 만들지 않습니다. 메시지 에이전트가 종료되고 재시작되면 재시작 중에 지속성 큐가 다시 선언되며, 어쨌든 지속된 메시지만 복원할 수 있습니다.
소비자
소비자 소비 뉴스. AMQP에서는 소비자가 대기 메시지를 받을 수 있는 두 가지 방법이 있습니다:
메시지 미들웨어는 소비자에게 메시지를 전달합니다 (푸시 API)
소비자는 적극적으로 메시지를 받는다 (풀 API)
참고: 여러 소비자가 같은 큐를 들을 경우, 큐 내 메시지는 한 명의 소비자만 소비됩니다(각 소비자당 한 번이 아닙니다)
메시지
메시지, 서비스, 애플리케이션 간에 전송되는 데이터는 속성과 본체로 구성됩니다.
속성은 메시지 우선순위, 지연 및 기타 고급 기능과 같은 메시지를 수정하며, 본문은 메시지 본문의 내용입니다.
메시지 속성:
- 콘텐츠 유형
- 콘텐츠 인코딩
- 라우팅 키
- 전달 방식 (영구 여부)
- 전달 모드 (영구 또는 비영속)
- 메시지 우선순위
- 메시지 게시 타임스탬프
- 만료 기간
- 출판사 애플리케이션 ID
메시지 본문:
속성 외에도 AMQP 메시지에는 페이로드(메시지가 실제로 전달하는 데이터)가 포함되어 있으며, AMQP 프록시는 이를 불투명한 바이트 배열로 취급합니다.
메시지 브로커는 페이로드를 검사하거나 수정하지 않습니다. 메시지는 페이로드를 포함하지 않고 속성만 포함할 수 있습니다. 일반적으로 JSON과 같은 직렬화된 형식을 사용하며, 비용 절감을 위해 프로토콜 버퍼와 MessagePack이 구조화된 데이터를 직렬화하여 메시지 페이로드로 게시합니다. AMQP와 그 동료들은 일반적으로 페이로드를 식별하기 위해 메시지와 통신할 때 "content-type"과 "content-encoding" 필드를 사용하지만, 이는 관례에 기반한 것입니다.
메시지 지속성:
메시지는 영구 방식으로 발행되며, AMQP 에이전트는 이 메시지를 디스크에 저장합니다. 서버가 재시작되면 시스템은 수신된 영속성 메시지가 손실되지 않았음을 확인합니다.
단순히 메시지를 영구 스위치로 보내거나 영속 큐로 라우팅한다고 해서 메시지가 영속성이 되는 것은 아닙니다: 메시지의 지속성은 전적으로 메시지 자체의 지속성 모드에 달려 있습니다.
메시지를 지속적으로 게시하면 성능에 영향을 줄 수 있습니다.
AMQP 작업 프로세스
출판사는 교환을 통해 메시지를 게시합니다.
스위치는 라우팅 규칙에 따라 스위치에 묶인 대기열에 들어오는 메시지를 분배합니다.
마지막으로 AMQP 에이전트는 이 큐에 가입한 소비자에게 메시지를 전달하거나, 소비자가 필요에 따라 스스로 메시지를 전달합니다.
AMQP 메시징 메커니즘
메시지 확인
소비자가 가끔 메시지를 처리하지 못하거나 직접 다운되기도 합니다. 네트워크 문제도 여러 문제를 일으킬 수 있습니다.
이로 인해 AMQP 상담원이 메시지를 삭제할 적절한 시기가 언제인지에 대한 질문이 생깁니다.
AMQP의 두 가지 메시지 확인 모드:
자동 확인 모드: 메시지 미들웨어가 소비자에게 메시지를 보내는 즉시 삭제합니다. (AMQP 방식 사용: basic.deliver 또는 basic.get-ok)
명시적 확인 모드: 소비자가 확인 응답을 보낼 때까지 기다린 후 메시지를 삭제합니다. (AMQP 메서드: basic.ack 사용 사용)
소비자가 확인 영수증을 보내지 않고 전화를 끊으면, AMQP 상담원이 메시지를 다른 소비자에게 다시 전달합니다. 그 시점에 이용 가능한 소비자가 없으면, 메시지 브로커는 다음 소비자가 이 대기열에 등록할 때까지 기다린 후 다시 전달을 시도합니다.
메시지 거부
소비자가 메시지를 받으면 처리 과정이 성공하거나 실패할 수 있습니다. 소비자는 메시지 브로커(메시지 미들웨어)에 메시지가 처리되지 않았거나 이 시점에서 완료되지 않았다고 "거부된 메시지"로 알릴 수 있습니다.
메시지가 거부되면, 소비자는 메시지 브로커에게 메시지를 어떻게 처리할지 - 파괴하거나 다시 큐에 넣을 수 있습니다.
이 큐에 소비자가 한 명뿐일 때는 메시지를 거부하고 다시 큐에 넣어 메시지가 같은 소비자 위에서 무한히 반복되도록 하지 않도록 주의하세요.
AMQP에서는 basic.reject 메서드를 사용하여 메시지 거부 작업을 수행합니다. 하지만 basic.reject에는 제한이 있습니다: 여러 메시지를 확인 응답이 포함된 것을 거부하는 데 사용할 수 없습니다. 하지만 RabbitMQ를 사용한다면, AMQP 0-9-1 확장 기능인 negative acknowledgements(nacks라고도 함)를 사용해 이 문제를 해결할 수 있습니다.
원문 언어:하이퍼링크 로그인이 보입니다.
|
게시됨 2022. 8. 14. 오후 11:22:55
|
|
|
|
