当消息放入 MQ（消息队列）时，生产者是否等待 MQ 管理器的 ACK？

Question

What I know is that Queues are used for asynchronous processing but I am wondering if the producer waits for an ACK from the MQ Manager to know that the message has been successfully put in the Message Queue, I am asking this because I have seen several sequence diagrams in my company where a Producer puts a message into a Message Queue and as a return it gets an ACK. But if it waits for ACK wouldn't it turn it into a synchronous process instead of asynchronous?

Answer 1

The exact behavior here would depend on the specific client implementation. That said, JMS allows both persistent and non-persistent messages and those will generally be sent blocking/synchronous and non-blocking/asynchronous respectively.

To be clear, persistent messages are those which should be written to durable storage (eg disk) by the broker so that in the event the broker shuts down or crashes the message will survive and be reloaded when the broker restarts. The idea is that persistent messages are therefore important enough that sending them should wait for a response from the broker to ensure the message arrived at the broker safely as expected. Generally speaking this usually isn't referred to as an "ACK." That terms usually denotes what happens when a client consumes and message and then tells the broker it is safe to remove the message from its memory/storage.

When folks talk about "asynchronous messaging" they aren't talking about the specific blocking semantics for sending a message. They are talking about the fact that producers are 100% disconnected from consumers. In other words, when a producer sends a message to a destination it doesn't care how quickly a consumer might receive that message or if there are any consumers at all. It simply sends the message. Likewise, a consumer listens for messages with no regard for how the producers operate or indeed if there are any producers at all. It simply receives and acknowledges messages, and it's important to note that this acknowledgement process is only between the consumer and the broker. The producer is not involved in that at all.

In short, just because pieces of the component processes involve blocking operations doesn't mean that the process as a whole isn't asynchronous.

Answer 2

Operations between clients and any MQ broker are strictly synchronous in a down-to-wire diagram. Under microscope view MQ messaging is always state machine implemented using direct calls between server and client, no matter which protocol is used. So, your ACK packets will be sent synchronously in a request reply coordination of calls between client and broker. There is no such thing as asynchronous messaging on wire level.

However, the very same process is asynchronous from a bird eye view of architecture of system. Goal of messaging is not to speak to a broker but to a message receiver. From this perspective sending of a message is separated operation from consuming a message. By using broker producers of messages do not talk directly to consumers and that is why it is called asynchronous.

Without message brokers, producers and consumers have to be directly wired. Any operation initiated by producer is directly mirrored on consumer side. Synchronous calls, like REST, are thus close coupled. Downtime of any entity is also downtime of all system. MQ-ing is breaker of this close coupling and lets both entities to do job at their pace.

Within JMS api itself there is other definition of synchronous and asynchronous calls. Do not confuse it with synchronous and asynchronous messaging. All JMS/MQ-ing is asynchronous from architecture view. But JMS lets the programmer to use two threading models: blocking thread model (synchronous one) and callback based model (asynchronous one). This is sync/async thread control, and not sync/async messaging. Messaging using JMS is always asynchronous.

The guy who named "blocking calls" as "synchronous" and "callback calls" as "asynchronous" within api intended for asynchronous messaging deserves to be shot. Plain stupidity.