메시지 큐

이 글은 검증을 위해 추가 인용문이 필요합니다. 신뢰할 수 있는 출처에 인용문을 추가하여 이 기사를 개선하는 데 도움을 주십시오. 조달되지 않은 자재는 제거될 수 있습니다.출처 찾기 : "메시지 큐"– 뉴스 · 신문 · 도서 · 학자 · JSTOR (2009년 5월) (이 템플릿메시지 삭제 방법 및 삭제 시기 확인)

컴퓨터 과학에서 메시지 큐와 메일박스는 일반적으로 프로세스 간 통신(IPC) 또는 동일한 프로세스 내의 스레드 간 통신에 사용되는 소프트웨어 엔지니어링 컴포넌트입니다.이들은 메시지 큐(제어 또는 콘텐츠 전달)를 사용합니다.그룹 통신 시스템은 유사한 종류의 기능을 제공합니다.

메시지 큐 패러다임은 퍼블리셔/서브스크라이버 패턴의 형제이며, 일반적으로 보다 큰 메시지 지향 미들웨어 시스템의 일부입니다.대부분의 메시징 시스템은 API에서 퍼블리셔/서브스크라이버 및 메시지큐 모델(JMS)을 모두 지원합니다.

송금 및 소유권

메시지 큐는, 복수의 프로세스/스레드간에 비동기 통신 패턴을 실장합니다.이것에 의해, 송신측과 수신측이 동시에 메시지큐와 대화할 필요는 없습니다.큐에 저장되는 메시지는 수신인이 가져올 때까지 저장됩니다.메시지 큐에는 단일 메시지로 전송할 수 있는 데이터의 크기 및 ^[1]큐에서 미처리 상태로 남아 있는 메시지의 수에 대한 암묵적 또는 명시적 제한이 있습니다.

송금하다

메시지 큐의 많은 구현은 운영 체제 내에서 또는 응용 프로그램 내에서 내부적으로 기능합니다.이러한 큐는 해당 시스템만을 ^[2][3][4]위해 존재합니다.

그 외의 실장에서는, 복수의 컴퓨터 시스템간에 메세지를 전달할 수 있어 복수의 애플리케이션과 복수의 operating ^[5]system을 접속할 가능성이 있습니다.이러한 메시지 큐잉 시스템은 일반적으로 시스템 장애 발생 시 메시지가 손실되지 않도록 복원 기능을 제공합니다.이러한 종류의 메시지 큐잉 소프트웨어(메시지 지향 미들웨어라고도 함)의 상용 구현 예로는 IBM MQ(구 MQ 시리즈) 및 Oracle Advanced Queuing(AQ)이 있습니다.Java Message Service라고 불리는 Java 표준이 있습니다.Java Message Service에는 몇 가지 독점 소프트웨어 및 무료 소프트웨어 구현이 있습니다.

VxWorks 및 QNX와 같은 실시간 운영 체제(RTOS)는 메시지 큐잉을 주요 프로세스 간 또는 스레드 간 통신 메커니즘으로 사용할 것을 권장합니다.이로 인해 메시지 전달과 CPU 스케줄링이 통합될 수 있습니다.스레드 간 통신을 위한 메시지 큐 기반을 장려한 상용 RTOS의 초기 예로는 VRTX와 pSOS+가 있으며, 둘 다 1980년대 초로 거슬러 올라간다.Erlang 프로그래밍 언어는 프로세스를 사용하여 동시성을 제공합니다.이러한 프로세스는 메시지 큐잉을 사용하여 비동기적으로 통신합니다.

소유권

메시지 큐소프트웨어는 독자 사양 또는 오픈소스 또는 둘 다 혼재할 수 있습니다.그런 다음 프라이빗 서버 또는 외부 클라우드 서버(메시지 큐잉 서비스)에서 실행됩니다.

• 독점 옵션에는 가장 오랜 역사가 있으며 IBM MQ 등의 메시지큐잉 초기 제품 및 Microsoft Message Queuing(MSMQ; 메시지큐잉) 등의 특정 운영시스템에 연결된 제품이 포함됩니다.클라우드 서비스 공급자는 또한 Amazon SQS(Simple Queue Service), StormMQ, Solace 및 IBM MQ와 같은 자체 솔루션을 제공합니다.
• 메시징 미들웨어 시스템의 오픈 소스에는 Apache ActiveMQ, Apache Kafka, Apache Qpid, Apache RocketMQ, Enduro/X, JBoss Messaging, JORAM, RabbitMQ, Sun Open Message Queue, Tarantool 등이 있습니다.

하드웨어 기반 메시징 미들웨어 공급업체의 예로는 Solace, Apigee 및 IBM MQ가 있습니다.

사용.

일반적인 메시지 큐잉 구현에서는 시스템 관리자가 메시지 큐잉 소프트웨어(큐 매니저 또는 브로커)를 설치 및 설정하고 이름 있는 메시지큐를 정의합니다.또는 메시지 큐잉 서비스에 등록합니다.

그런 다음 애플리케이션은 큐에 배치된 메시지를 "수신"하는 소프트웨어 루틴을 등록합니다.

두 번째 이후의 애플리케이션은 큐에 접속하여 메시지를 큐로 전송할 수 있습니다.

큐 매니저 소프트웨어는 수신 응용 프로그램이 연결되고 등록된 소프트웨어 루틴이 호출될 때까지 메시지를 저장합니다.그런 다음 수신 응용 프로그램은 메시지를 적절한 방법으로 처리합니다.

대부분의 경우 메시지 전달의 정확한 의미론에는 다음과 같은 다양한 옵션이 있습니다.

• 내구성 – 신뢰성에 대한 요구가 리소스 집약적인 솔루션을 나타내는 경우 메시지를 메모리에 저장하거나 디스크에 쓰거나 DBMS에 커밋할 수 있습니다.
• 보안 정책 – 이러한 메시지에 액세스할 수 있는 애플리케이션은 무엇입니까?
• 메시지 삭제 정책– 큐 또는 메시지에 "존속 가능 시간"이 있을 수 있습니다.
• 메시지 필터링 – 일부 시스템에서는 데이터 필터링을 지원하므로 사용자는 지정된 특정 대상 기준에 일치하는 메시지만 볼 수 있습니다.
• 전달 정책 – 메시지가 적어도 한 번 또는 두 번 이상 전달되지 않도록 보장해야 합니까?
• 라우팅 정책– 다수의 큐서버가 있는 시스템에서는 어떤 서버가 메시지 또는 큐의 메시지를 수신해야 합니까?
• 배치 정책– 메시지를 즉시 전달해야 합니까?아니면 시스템이 조금 기다렸다가 많은 메시지를 한 번에 전달해야 할까요?
• 큐잉 기준 – 메시지는 언제 "큐잉"으로 간주해야 합니까?큐에 언제 있어요?또는 적어도 1개의 리모트큐에 전송되었을 때?아니면 모든 큐에?
• 수신 통지: 퍼블리셔는 일부 또는 모든 서브스크라이버가 메시지를 수신했을 때 알아야 할 수 있습니다.

이것들은 모두 트랜잭션 의미론, 시스템 신뢰성 및 시스템 효율성에 상당한 영향을 미칠 수 있는 고려 사항입니다.

표준 및 프로토콜

지금까지 메시지 큐잉은 독자적인 클로즈드 프로토콜을 사용하여 서로 다른 운영 체제 또는 프로그래밍 언어가 이기종 환경에서 상호 작용하는 기능을 제한해 왔습니다.

메시지 큐잉을 보다 보편적으로 만들기 위한 초기 시도는 클라이언트 API의 Java 전용 추상화를 제공하는 Sun Microsystems의 JMS 사양이었다.이를 통해 Java 개발자는 SQL 데이터베이스를 사용하는 개발자와 유사한 방식으로 메시지 큐 공급자를 전환할 수 있습니다.실제로 메시지 큐잉 기술과 시나리오의 다양성을 고려할 때, 이것이 항상 가능한 만큼 실용적인 것은 아니었습니다.

오픈 소스 메시지큐 구현에 사용되는3가지 표준이 등장했습니다.

1. AMQP(Advanced Message Queuing Protocol) – 2014년 4월 이후 ISO/IEC 19464로 승인된 풍부한 기능을 갖춘 메시지 큐 프로토콜
2. Streaming Text Oriented Messaging Protocol (STOMP)– 심플한 텍스트 지향 메시지 프로토콜
3. MQTT(구 MQ Telemetry Transport) – 특히 임베디드 디바이스용 경량 메시지 큐 프로토콜

이러한 프로토콜은 표준화 및 채택의 서로 다른 단계에 있습니다.첫 번째 2개는 HTTP, MQTT와 같은 레벨로 TCP/IP 레벨로 동작합니다.

일부 독점 구현에서는 HTTP를 사용하여 Amazon의 SQS와 같은 일부 구현에 의한 메시지 큐잉을 제공합니다.이는 요청-응답 시멘틱스를 사용하여 동기 프로토콜을 통해 비동기 동작(메시지 큐잉에 필요한 동작)을 계층화할 수 있기 때문입니다.그러나, 이러한 구현은 이 경우 기본 프로토콜에 의해 제약되며, 위의 메시지 전달에 필요한 완전한 충실도 또는 옵션 세트를 제공할 수 없을 수 있습니다.

동기 대 비동기

널리 알려진 통신 프로토콜의 대부분은 동시에 작동합니다.HTTP 프로토콜(World Wide Web 및 웹 서비스에서 사용됨)은 사용자가 웹 페이지에 대한 요청을 보낸 후 응답을 기다리는 명백한 예를 제공합니다.

그러나 동기 동작이 적절하지 않은 시나리오가 존재합니다.예를 들어 AJAX(Asynchronous JavaScript and XML)를 사용하여 텍스트, JSON 또는 XML 메시지를 비동기적으로 전송하여 웹 페이지의 일부를 관련 정보로 업데이트할 수 있습니다.Google은 사용자의 부분적으로 입력된 쿼리를 Google 서버로 보내고 사용자가 입력 과정에 관심이 있을 수 있는 전체 쿼리 목록을 반환하는 검색 기능인 Google 제안에서 이 접근 방식을 사용합니다.이 목록은 사용자 유형에 따라 비동기적으로 업데이트됩니다.

기타 비동기 예는 이벤트 알림 시스템 및 게시/구독 시스템에 존재합니다.

• 응용 프로그램은 이벤트가 발생했음을 다른 사용자에게 통지해야 할 수 있지만 응답을 기다릴 필요는 없습니다.
• 퍼블리시/서브스크라이브 시스템에서는, 애플리케이션은 임의의 수의 클라이언트가 읽을 수 있도록 정보를 「퍼블리시」합니다.

위의 두 예에서 예를 들어 수신자 중 하나가 크래쉬 했을 경우, 정보의 송신자가 대기할 필요가 있는 것은 의미가 없습니다.

애플리케이션은, 배타적으로 동기 또는 비동기일 필요는 없습니다.인터랙티브한 어플리케이션은 요청의 특정 부분에 즉시 응답해야 할 수 있습니다(예: 판매 요청이 접수되었음을 고객에게 알리고 재고에서 인출하겠다는 약속을 처리하는 등). 그러나 다른 부분은 큐잉할 수 있습니다(과금 계산 완료, 중앙 회계 시스템에 데이터 전송, 모든 종류의 호출 등).(기타 서비스의 경우)는 잠시 후에 완료됩니다.

이러한 모든 상황에서 메시지 큐잉(또는 브로드캐스트메시지 시스템)을 실행하는 서브시스템을 갖추면 시스템 전체의 동작을 개선하는 데 도움이 됩니다.

UNIX에서의 실장

UNIX에서는 일반적으로 두 가지 메시지큐 구현이 있습니다.하나는 SYS V API의 일부이고 다른 하나는 POSIX의 일부입니다.

시스템 V

UNIX SYS V는 연결된 목록의 배열을 메시지 큐로 유지함으로써 메시지 전달을 구현합니다.각 메시지 큐는 배열 내의 인덱스에 의해 식별되며 고유한 설명자가 있습니다.특정 인덱스는 여러 개의 설명자를 가질 수 있습니다.UNIX는 메시지 전달 ^[6]기능에 액세스하기 위한 표준 기능을 제공합니다.

msgget()

이 시스템 콜은 키를 인수로 사용하여 일치하는 키가 있는 큐 기술자를 반환합니다(있는 경우).존재하지 않는 경우,IPC_CREAT플래그가 설정되면 지정된 키를 사용하여 새 메시지큐를 만들고 해당 디스크립터를 반환합니다.

msgrcv()

지정된 큐 기술자로부터 메시지를 수신하기 위해 사용됩니다.발신자 프로세스에는 큐에 대한 읽기 권한이 있어야 합니다.2종류입니다.^[7]

• 수신을 차단하면 요청된 메시지 유형을 찾을 수 없는 경우 자녀가 절전 모드로 전환됩니다.큐에 다른 메시지가 게시될 때까지 sleep 상태로 있다가 다시 확인하도록 웨이크업합니다.
• 논블로킹 수신이 실패했음을 나타내는 즉시 발신자에게 반환됩니다.

msgctl()

소유자와 같은 메시지큐 파라미터를 변경하기 위해 사용됩니다.가장 중요한 것은 메시지큐를 삭제하기 위해 사용되는 것입니다.IPC_RMIDflag. 메시지 큐는 작성자, 소유자 또는 슈퍼 사용자만 삭제할 수 있습니다.

POSIX

POSIX.1-2001 메시지큐 API는 2개의 UNIX 메시지큐 API 중 후반입니다SYS V API와는 다르지만 유사한 기능을 제공합니다.unix man 페이지mq_overview(7)에 POSIX 메시지큐의 개요를 나타냅니다.

그래피컬 사용자 인터페이스

Graphical User Interface(GUI; 그래피컬사용자 인터페이스)는 이벤트큐 또는 입력큐라고도 불리는 메시지큐를 사용하여 마우스 클릭, 키보드이벤트 또는 기타 사용자 입력 등의 그래픽 입력 액션을 응용 프로그램 ^[8]프로그램에 전달합니다.윈도우 시스템은 사용자 또는 타이머틱이나 다른 스레드에서 전송된 메시지 등 다른 이벤트를 나타내는 메시지를 메시지큐에 넣습니다GUI 애플리케이션은, 다음의 루틴을 호출하는 것으로써, 이러한 이벤트를 1개씩 삭제합니다.getNextEvent()이벤트 루프에서 또는 유사한 것을 호출한 후 ^[9]해당 이벤트를 처리하기 위해 적절한 애플리케이션 루틴을 호출합니다.

「 」를 참조해 주세요.

레퍼런스