그리고 있나요? 나에게 MB는 구독자와 게시자를 모두 알고 있으며 중재자 역할을하여 구독자에게 새 메시지 (효과적으로 "푸시"모델)를 알립니다. 반면 MQ는 소비자가 큐에서 메시지를 가져 오는 "풀 (pull)"모델에 가깝습니다.

내가 여기서 완전히 벗어 났습니까?

대체로 공급 업체 소프트웨어 제품의 경우 서로 바꿔서 사용할 수 있으며 설명하는대로 밀어 넣기 또는 끌어 오기 측면에서 강력한 구별이 없습니다.

버스 대에 QUEUE 실제로 가장 최근에 IBM MQ 및 팁코 랑데뷰와 같은 시스템에 따른 다소 기존의 개념입니다. MQ는 원래 1 : 1 시스템이었으며 실제로 다양한 시스템을 분리하는 대기열이었습니다.

반면에 Tibco는 메시징 백본 (판매)으로 동일한 주제에 대해 여러 게시자와 구독자가있을 수 있습니다.

그러나 최근에는 둘 다 (그리고 더 새로운 경쟁 제품) 서로의 공간에서 플레이 할 수 있습니다. 둘 다 인터럽트 및 새 메시지 폴링으로 설정할 수 있습니다. 둘 다 다양한 시스템 간의 상호 작용을 중재합니다.

그러나 message-queue 라는 문구 는 내부 스레드 내 메시지 펌프 등에 사용되며, 이러한 맥락에서 사용 방식은 실제로 다릅니다. 고전적인 Windows 메시지 펌프를 생각한다면 이것은 실제로 설명하는 풀 모델에 가깝지만 실제로는 앱 간 또는 상자 간보다는 앱 내입니다.

메시지 버스

메시지 버스는 다른 시스템이 통해 통신 할 수 있도록 메시징 인프라 인터페이스를 공유 세트 ( 메시지 버스 ).

출처 : EIP

메시지 큐

메시지 큐 의 기본 아이디어 는 간단합니다.

• 두 개 이상의 프로세스 가 공통 시스템 메시지 대기열에 대한 액세스를 통해 정보를 교환 할 수 있습니다 .

• 전송 프로세스는 일부 (OS) 메시지 전달 모듈을 통해 다른 프로세스에서 읽을 수있는 큐에 메시지를 배치합니다.

출처 : Dave Marshall

이미지 소스

차

Message Queue는 포함 FIFO ( 선입 에있는 반면, 규칙) 메시지 버스는 하지 않습니다.

결론

두 LOOK 둘 사이에 메시지를 전달 - 작품의 같은 종류의 일을 같은 응용 프로그램 이나 모듈 또는 인터페이스 또는 시스템 이나 프로세스 의 작은 차이를 제외하고, FIFO

일부 제품은 이전에 하나 또는 다른 범주에만 속했던 기능을 지원하기 때문에이 두 개념 사이의 경계가 약간 모호해졌습니다 (예 : Azure Service Bus는 두 가지 접근 방식 모두 지원).

열

메시지 대기열은 응용 프로그램에서 메시지를 수신하여 FIFO (선입 선출) 방식으로 하나 이상의 다른 응용 프로그램에서 사용할 수 있도록합니다. 많은 아키텍처 시나리오에서 애플리케이션 A가 애플리케이션 B와 C에 업데이트 나 명령을 보내야하는 경우 B와 C에 대해 별도의 메시지 큐를 설정할 수 있습니다. A는 각 큐에 별도의 메시지를 쓰고 각 종속 애플리케이션은 해당 큐에서 읽습니다. 자신의 대기열 (대기열에서 제거 될 때 제거되는 메시지). A가 업데이트를 보내기 위해 B와 C를 모두 사용할 수있을 필요는 없습니다. 각 메시지 큐는 영구적이므로 애플리케이션이 다시 시작되면 다시 온라인 상태가되면 큐에서 가져 오기 시작합니다. 이를 통해 종속 시스템 간의 종속성을 해제하고 응용 프로그램에 더 큰 확장 성과 내결함성을 제공 할 수 있습니다.

버스

메시지 버스 또는 서비스 버스는 하나 이상의 애플리케이션이 하나 이상의 다른 애플리케이션에 메시지를 전달하는 방법을 제공합니다. 선입 선출 주문이 보장되지 않을 수 있으며 버스 가입자는 메시지 발신자에 대한 지식 없이도 출입 할 수 있습니다. 따라서 메시지 버스를 통해 애플리케이션 B에 상태 업데이트를 전달하도록 애플리케이션 A를 작성할 수 있습니다. 나중에 이러한 업데이트의 혜택을받을 수있는 애플리케이션 C가 작성됩니다. 애플리케이션 C는 애플리케이션 A에 대한 업데이트 없이도 메시지 버스를 수신하고 이러한 업데이트를 기반으로 조치를 취하도록 구성 할 수 있습니다. 보내는 애플리케이션이 모든 큐에 메시지를 명시 적으로 추가하는 큐와 달리 메시지 버스는 게시 / 구독 모델. 메시지가 버스에 게시되고 해당 유형의 메시지를 구독 한 모든 애플리케이션이이를 수신합니다.

출처

다른 답변에서 명시 적으로 언급되지 않은 주요 차이점은 메시지 버스는 여러 가입자를 허용하는 반면 대기열은 대기열을 수신하는 모든 항목에 하나씩 항목을 대기열에서 빼는 것입니다. 여러 리스너가 동일한 항목이 대기열에서 나오는 것을 보도록하려면 직접 처리해야합니다. 서비스 버스가이 작업을 즉시 수행합니다.

내가 보는 방식은 Message Queue가 Message Bus를 만드는 것 입니다. 클라이언트 (즉, 노드)는 메시지 버스를 수신 할 수 있습니다. 이는 UDP를 통해 메시지를 브로드 캐스팅하는 MQ가있는 경우에 특히 그렇습니다. 즉, 메시지를받을 사람을 알거나 신경 쓰지 않고 브로드 캐스트 / 멀티 캐스트 주소로 메시지를 보내는 경우입니다. 이 시나리오에 대한 자세한 설명은 이 문서를 참조하십시오 .

서비스 버스는 메시지 큐보다 더 일반적인 용어입니다.

MQ는 단순한 FIFO이지만 서비스 버스, 즉 메시지 조작을위한 거대한 "중심"인 이벤트 허브를 구현하는 더 정교한 방법이 있습니다. MQ에서 제공하는 기능 외에도 메시지 저장 (따라서 여러 구독자 사용) 등이 가능합니다.

메시지 버스는 일대 다 배포 모델입니다. 이 모델의 대상은 일반적으로 주제 또는 주제라고합니다. 사용하는 모든 구독자가 동일한 게시 된 메시지를받습니다. 이것을 '방송'모델이라고 부를 수도 있습니다. 분산 컴퓨팅을위한 Observer 디자인 패턴에서 주제를 주제와 동일하게 생각할 수 있습니다. 일부 메시지 버스 공급자는이를 TCP 대신 UDP로 구현하는 것을 효율적으로 선택합니다. 주제의 경우 메시지 전달은 '불 사실'입니다. 아무도 듣지 않으면 메시지가 사라집니다. 그것이 원하는 것이 아니라면 '지속 가능한 구독'을 사용할 수 있습니다.

메시지 큐는 메시지의 일대일 대상입니다. 메시지는 소비하는 수신자 중 한 명만 수신합니다 (참고 : '주제 클라이언트에 대해 구독자를 지속적으로 사용하고 큐 클라이언트에 대해 수신자를 사용하면 혼동을 피할 수 있습니다). 큐에 전송 된 메시지는 누군가가 큐를 선택하거나 만료 될 때까지 디스크 또는 메모리에 저장됩니다. 따라서 대기열 (및 지속 구독)에는 활성 스토리지 관리가 필요하므로 느린 소비자를 고려해야합니다.

대부분의 환경에서는 아키텍처를 변경하지 않고도 항상 추가 구성 요소를 추가 할 수 있기 때문에 주제가 더 나은 선택이라고 생각합니다. 추가 된 구성 요소는 모니터링, 로깅, 분석 등이 될 수 있습니다. 프로젝트를 시작할 때 1 년, 5 년, 10 년 후 요구 사항이 어떻게 될지 알 수 없습니다. 변화는 불가피합니다. 수용하십시오 :-)