隊列模型

隊列模型提供高可靠、高并發的一對一消費模型，即隊列中的每一條消息都只能夠被某一個消費者消費。

隊列就像一家旋轉壽司店。壽司店中有多個壽司師傅（生產者）在制作精美的壽司，每一份壽司都是獨特的，顧客（消費者）可以從傳送帶上拿取中意的壽司進行食用（消費）。

隊列模型消息流

如隊列模型消息流所示，應用系統A（生產者）向隊列發送消息，應用系統B（消費者）從隊列取出消息。

隊列模型特性

• 多種隊列模式

  支持普通隊列、延遲隊列。您可以個性化地配置隊列屬性以滿足不同應用場景。

• 海量并發訪問

  支持多個生產者和消費者并發訪問同一隊列，并能確保某條消息在取出之后的特定時間內，無法被其他消費者獲得。您可以根據業務需求自由伸縮并發訪問數。

• 消息投遞保障

  在消息有效期內，確保消息至少能被成功消費一次。輕量消息隊列（原 MNS）接入阿里云賬號體系，用戶間資源隔離，確保隊列中的消息不會被非法獲取。

• 分布式事務消息

  提供完善的分布式環境下事務消息解決方案。

• 日志管理

  支持查看每條消息的完整生命周期事件，包括發送、接收和刪除，方便問題排查。更多信息，請參見日志管理概述。

• 云監控

  支持查看隊列情況，并且可以自定義報警項，當隊列情況不符合期望時，您能夠及時知曉。更多信息，請參見云監控。

主題模型

主題模型提供一對多的發布訂閱模型，支持消息通知。

主題就像一份報紙，多個讀者到郵局訂閱了這份報紙。當報紙推出最新一期時，讀者（包括郵局的合作伙伴）可以選擇以下方式來獲取：

• 讓郵局投遞員將報紙都投遞（推送）到家里（特定的地址）。

• 去就近的報刊亭（訂閱點）自行獲取報紙（報紙會先被郵局投遞員集中送到各個報刊亭）。

主題模型消息流

如主題模型消息流所示：

• 主題上有多個訂閱，每個訂閱對應不同的隊列。

• 一條消息發布到主題后，會被分別推送到不同的訂閱指定的隊列。

• 訂閱支持消息過濾，您可在訂閱中指定過濾標簽。

  • 未指定過濾標簽的訂閱：無論消息有沒有指定消息標簽，都可以推送到指定的隊列。

  • 已指定過濾標簽的訂閱：只有消息指定了匹配的消息標簽，才會推送到指定的隊列。

主題模型特性

• 通知消息

  • 輕量消息隊列（原 MNS）服務端主動推送消息到指定隊列，減少用戶端輪詢和資源消耗，使您可以專注于業務邏輯，避免對其他消息服務客戶端的依賴及過多代碼影響服務穩定性。更多信息，請參見Endpoint簽名認證和主題使用手冊。

  • 對于因網絡或其他原因無法提供回調地址的情況，輕量消息隊列（原 MNS）仍支持將消息推送到隊列，您可以直接從隊列獲取消息。原先使用隊列模型的消費者可無縫消費主題中的消息。更多信息，請參見隊列和廣播拉取消息模型。

• 一對多廣播消息

  一條發布到主題中的消息可被多個訂閱者訂閱。輕量消息隊列（原 MNS）會按照各訂閱者指定的隊列推送消息。發布一次即可推送到多個接收端，保證消息發布的原子性。

• 消息標簽過濾

  在支持一對多廣播消息的基礎上，在訂閱中還支持對消息進行過濾。可以訂閱主題中帶有特定標簽的消息。在創建訂閱時指定消息過濾標簽，然后PublishMessage時指定消息標簽，輕量消息隊列（原 MNS）在推送消息時會根據標簽進行過濾，僅推送消息標簽與訂閱中指定的過濾標簽匹配的消息到指定隊列上。更多信息，請參見主題接口規范。

• 消息投遞

  輕量消息隊列（原 MNS）支持將消息推送到隊列。更多信息，請參見隊列和廣播拉取消息模型。

• 消息投遞保障 ：在消息有效期內，保證發布到主題中的消息會按照指定的策略和格式推送給用戶端程序。更多信息，請參見NotifyStrategy。

• 多種消息格式

  • XML：消息體為XML格式，包含消息正文和消息屬性。

  • JSON：消息體為JSON格式，包含消息正文和消息屬性。

  • SIMPLIFIED：消息體即用戶端發布的消息，不包含任何屬性信息（精簡格式，即文本格式）。更多信息，請參見：

    • NotifyStrategy

    • NotifyContentFormat

• 日志管理

  支持查看每條消息發布進主題的記錄和每次推送給用戶端的記錄，包括重試推送的記錄和結果等，能夠全面展示每條消息的生命周期，方便問題調查。更多信息，請參見日志管理概述。

• 云監控

  支持查看消息推送的記錄，當推送失敗次數比較多時，通過添加報警的方式及時知曉。更多信息，請參見云監控。