當消息放入 MQ（消息隊列）時，生產者是否等待 MQ 管理器的 ACK？

Question

我所知道的是隊列用於異步處理，但我想知道生產者是否等待來自 MQ 管理器的 ACK 來知道消息已成功放入消息隊列，我問這個是因為我看到了幾個序列在我公司的圖表中，生產者將一條消息放入消息隊列，作為返回，它得到一個 ACK。 但是如果它等待ACK，它會不會把它變成一個同步過程而不是異步過程？

Answer 1

此處的確切行為取決於特定的客戶端實現。 也就是說，JMS 允許持久性和非持久性消息，這些消息通常分別以阻塞/同步和非阻塞/異步方式發送。

需要明確的是，持久消息是那些應該由代理寫入持久存儲（例如磁盤）的消息，以便在代理關閉或崩潰的情況下消息將繼續存在並在代理重新啟動時重新加載。 這個想法是持久消息因此非常重要，發送它們應該等待代理的響應以確保消息按預期安全到達代理。 一般來說，這通常不稱為“ACK”。 該術語通常表示當客戶端消費和消息時發生的事情，然后告訴代理可以安全地從其內存/存儲中刪除消息。

當人們談論“異步消息傳遞”時，他們並不是在談論發送消息的特定阻塞語義。 他們談論的是生產者 100% 與消費者脫節的事實。 換句話說，當生產者向目的地發送消息時，它不關心消費者接收該消息的速度有多快，或者是否有任何消費者。 它只是發送消息。 同樣，消費者收聽消息時不考慮生產者的運作方式或者是否有任何生產者。 它只是接收和確認消息，重要的是要注意這個確認過程只發生在消費者和代理之間。 生產者根本不參與其中。

簡而言之，僅僅因為部分組件進程涉及阻塞操作並不意味着整個進程不是異步的。

Answer 2

客戶端和任何 MQ 代理之間的操作在下到線圖中是嚴格同步的。 在顯微鏡下，無論使用哪種協議，MQ 消息傳遞始終是使用服務器和客戶端之間的直接調用實現的狀態機。 因此，您的 ACK 數據包將在客戶端和代理之間調用的請求回復協調中同步發送。 沒有在線級別的異步消息傳遞之類的東西。

然而，從系統架構的鳥瞰圖來看，同樣的過程是異步的。 消息傳遞的目標不是與代理對話，而是與消息接收者對話。 從這個角度來看，發送消息是與使用消息分開的操作。 通過使用代理，消息生產者不會直接與消費者對話，這就是它被稱為異步的原因。

沒有消息代理，生產者和消費者必須直接連線。 生產者發起的任何操作都直接鏡像到消費者端。 因此，同步調用（如 REST）是緊耦合的。 任何實體的停機時間也是所有系統的停機時間。 MQ-ing 打破了這種緊密耦合，讓兩個實體按照自己的節奏完成工作。

在 JMS api 本身中有同步和異步調用的其他定義。 不要將它與同步和異步消息傳遞混淆。 從體系結構的角度來看，所有 JMS/MQ-ing 都是異步的。 但是 JMS 允許程序員使用兩種線程模型：阻塞線程模型（同步模型）和基於回調的模型（異步模型）。 這是同步/異步線程控制，而不是同步/異步消息傳遞。 使用 JMS 的消息傳遞始終是異步的。

在用於異步消息傳遞的 api 中將“阻塞調用”命名為“同步”並將“回調調用”命名為“異步”的人應該被槍斃。 純粹的愚蠢。