Message Queue와 Message Bus — 차이점은 무엇입니까?

Message Queue와 Message Bus — 차이점은 무엇입니까?

---

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

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

---

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

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

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

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

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

---

메시지 버스

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

출처 : EIP

메시지 큐

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

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

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

출처 : Dave Marshall

이미지 소스

차

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

결론

Both LOOK like doing same kind of work - passing messages between two Applications or Modules or Interfaces or Systems or Processes, except small difference of FIFO

---

There has been some blurring of the lines between these two concepts, as some products now support features that previously belonged only to one or the other category (for instance Azure Service Bus supports both approaches).

QUEUE

A message queue receives messages from an application and makes them available to one or more other applications in a first-in-first-out (FIFO) manner. In many architectural scenarios, if application A needs to send updates or commands to applications B and C, then separate message queues can be set up for B and C. A would write separate messages to each queue, and each dependent application would read from its own queue (the message being removed upon being dequeued). Neither B nor C need to be available in order for A to send updates. Each message queue is persistent, so if an application restarts, it will begin pulling from its queue once it is back online. This helps break dependencies between dependent systems and can provide greater scalability and fault tolerance to applications.

BUS

A message bus or service bus provides a way for one (or more) application to communicate messages to one or more other applications. There may be no guarantee of first-in-first-out ordering, and subscribers to the bus can come and go without the knowledge of message senders. Thus, an application A could be written to communicate status updates to application B via a message bus. Later, application C is written that can also benefit from these updates. Application C can be configured to listen to the message bus and take action based on these updates as well, without requiring any update to application A. Unlike queues, where the sending application explicitly adds messages to every queue, a message bus uses a publish/subscribe model. Messages are published to the bus, and any application that has subscribed to that kind of message will receive it. This approach allows applications to follow the open/closed principle, since they become open to future changes while remaining closed to additional modification.

SOURCE

---

The main difference which hasn't really been mentioned explicitly in the other answers is that a message bus allows for multiple subscribers whereas a queue will dequeue items one by one to anything listening to the queue. If you wanted multiple listeners to see the same items coming off the queue you'd have to handle that yourself, a service bus would do this out of the box for you.

---

The way I see it is that the Message Queue creates the Message Bus. Clients (i.e. nodes) can then listen to the message bus. This is particularly true for the case where you have a MQ broadcasting messages through UDP, in other words, it is sending messages to a broadcast/multicast address without knowing or caring who is going to be getting them. For a more in-depth description of this scenario you can check this article.

---

Service Bus is a more general term than a Message Queue.

MQ is a simple FIFO, but there are more sophisticated ways to implement a Service Bus, i.e. an Event Hub, which is a huge "center" for manipulating the messages. Beside the functionality provided by MQ, it allows for storing the messages (and hence using multiple subscribers) etc

참고 URL : https://stackoverflow.com/questions/7793927/message-queue-vs-message-bus-what-are-the-differences