儲存體佇列和服務匯流排佇列 - 異同比較

本文將分析 Microsoft Azure 所提供兩種佇列類型之間的差異和相似性：儲存體佇列和服務匯流排佇列。 透過這項資訊，您可以更明確的判斷哪種解決方案最符合需求。

簡介

Azure 支援兩種佇列機制：儲存體佇列和服務匯流排佇列。

儲存體佇列是 Azure 儲存體基礎結構的一部分。 可讓您儲存大量訊息。 使用 HTTP 或 HTTPS 透過境過驗證的呼叫，存取來自世界各地的訊息。 一則佇列訊息的大小可能高達 64 KB。 佇列可能包含數百萬則訊息，最高可達儲存體帳戶的總容量限制。 佇列通常用來建立工作待辦項目，以非同步處理。 如需詳細資訊，請參閱什麼是 Azure 儲存體佇列。

服務匯流排佇列是較廣泛 Azure 傳訊基礎結構的一部分，支援佇列處理、發佈/訂閱，以及更進階的整合模式。 這些功能的設計目的是為了整合可能跨多種通訊協定、資料合約、信任網域或網路環境的應用程式或應用程式元件。 如需服務匯流排佇列/主題/定用帳戶的詳細資訊，請參閱服務匯流排佇列、主題和訂用帳戶。

技術選擇考量

儲存體佇列和服務匯流排佇列具有稍微不同的功能集。 視您特定解決方案的需求而定，您可以選擇其中一者或同時選擇兩者。

在判斷哪一種佇列技術適合給定解決方案的目的時，解決方案架構設計人員和開發人員應該考慮這些建議。

請考慮使用儲存體佇列

身為方案架構設計人員/開發人員，您應該在下列情況中考慮使用儲存體佇列：

• 您的應用程式必須在佇列中儲存超過 80 GB 的訊息。
• 您的應用程式需要在佇列中追蹤處理訊息的進度。 如果處理訊息的背景工作角色損毀，這就很有用。 另一個背景工作角色可以接著使用該項資訊，從先前背景工作角色停止的地方繼續處理。
• 您需要針對您佇列所進行所有交易的伺服器端記錄。

請考慮使用服務匯流排佇列

身為方案架構設計人員/開發人員，您應該在下列情況中考慮使用服務匯流排佇列：

• 您的解決方案必須接收訊息，而不需要輪詢佇列。 透過服務匯流排，您即可使用服務匯流排支援的 TCP 型通訊協定，利用長時間輪詢接收作業來達成此目的。
• 您的解決方案需要佇列提供保證的先進先出 (FIFO) 排序的傳遞。
• 您的解決方案必須支援自動重複偵測。
• 您想要讓應用程式將訊息當成長時間執行的平行資料流來處理 (訊息是透過訊息上的 [工作階段識別碼] 屬性與資料流相關聯)。 在此模型中，取用應用程式中的每個節點會相競取得串流，而不是訊息。 對取用結點提供串流時，結點可能會使用交易檢查應用程式串流狀態的狀態。
• 當您在傳送或接收佇列發出的多則訊息時，您的解決方案需要交易行為和不可部分完成的作業。
• 您的應用程式會處理超過 64 KB 但通常不到 256 KB 或 1 MB 限制的訊息，視所選的服務層級而定 (雖然服務匯流排佇列可以處理最多 100 MB 的訊息)。
• 您需要提供角色型存取模型給佇列，並且針對傳送者和接收者提供不同的權限。 如需詳細資訊，請參閱下列文章：
  • 使用受控識別進行驗證
  • 從應用程式進行驗證
• 您的佇列大小不會增長到 80 GB 以上。
• 您想要使用 AMQP 1.0 標準型傳訊通訊協定。 如需 AMQP 的詳細資訊，請參閱服務匯流排 AMQP 概觀。
• 您預計最終會從佇列型點對點通訊移轉到發佈訂閱傳訊模式。 此模式可讓其他接收者 (訂閱者) 整合。 每個接收者都會接收部分或所有傳送至佇列的訊息獨立複本。
• 您的訊息方案必須支援「最多一次」和「至少一次」傳遞保證，而不需要建置其他基礎結構元件。
• 您的解決方案需要發佈及取用批次訊息。

比較儲存體佇列和服務匯流排佇列

下列各節的資料表會依邏輯分組列出佇列功能， 讓您一眼就能比較 Azure 儲存體佇列和服務匯流排佇列所提供的功能。

基本功能

本節將比較儲存體佇列和服務匯流排佇列所提供的一些基本佇列功能。

其他資訊

• 儲存體佇列中的訊息通常是先進先出，但有時也不按順序。 例如，當用戶端應用程式在處理訊息時當機，而導致訊息的可見度逾時持續時間到期時。 當可視性逾時到期時，訊息會再次出現在佇列上，以便其他工作者清除佇列中的訊息。 此時，佇列中可能放入新出現的訊息，等待再次從佇列中清除。
• 服務匯流排佇列中的保證 FIFO 模式需要使用訊息工作階段。 如果應用程式在處理以查看與鎖定模式所接收的訊息時損毀，下一次佇列接收者接受訊息工作階段時，將會在工作階段的鎖定持續時間到期之後，從失敗的訊息開始處理。
• 儲存體佇列的設計目的是支援標準佇列案例，例如下列佇列案例：
  • 將應用程式元件分離，以提高可延展性和失敗的容錯度
  • 負載調節
  • 建置流程工作流程。
• 若要避免有關訊息處理服務匯流排會話內容中的訊息處理不一致，可使用工作階段狀態來儲存應用程式相對於處理工作階段訊息順序的進度，以及使用有關解決已接收訊息和更新工作階段狀態的交易。 這種一致性功能有時會在其他廠商的產品中標示為「僅處理一次」。 任何交易失敗都顯然會導致訊息重新傳遞，因此這種說法並不完全適合。
• 儲存體佇列提供跨佇列、資料表和 BLOB 之統一且一致的程式設計模型，適合開發人員和營運團隊使用。
• 服務匯流排佇列支援在單一佇列內容中進行本機交易。
• 服務匯流排所支援的「接收與刪除」模式可讓您降低訊息作業計數 (以及關聯的成本)，但是也會降低傳遞保證。
• 儲存體佇列可讓租用延長訊息的租用。 此功能可讓背景工作處理序維持短期的訊息租用。 因此，如果某個背景工作角色損毀，就可以由另一個背景工作角色快速地重新處理訊息。 此外，如果背景工作角色需要的處理時間超過目前的租用時間，也可以延長訊息的租用。
• 儲存體佇列提供您可以在將訊息加入佇列或從佇列中清除訊息時設定的可視性逾時。 此外，您可以在執行階段使用不同的租用值來更新訊息，並且在相同佇列的訊息之間更新不同的值。 服務匯流排鎖定逾時會在佇列中繼資料中定義。 然而，您可以為訊息鎖定手動更新預先定義的鎖定持續時間，或使用自動鎖定更新功能，讓用戶端為您管理鎖定更新。
• 在服務匯流排佇列中，封鎖接收作業的最大逾時值是 24 天。 但是，REST 架構的最大逾時值為 55 秒。
• 服務匯流排所提供的用戶端批次允許佇列用戶端將多個訊息批次處理成單一傳送作業。 批次處理僅適用於非同步傳送作業。
• 儲存體佇列的 200 TB 上限 (當您虛擬化帳戶時則更多) 和無限佇列等功能，使它成為 SaaS 提供者的理想平台。
• 儲存體佇列提供彈性、高效能的委派存取控制機制。

進階功能

本節將比較儲存體佇列和服務匯流排佇列所提供的進階功能。

其他資訊

• 這兩種佇列技術都可讓訊息排定在稍後傳遞。
• 佇列自動轉送可讓數以千計的佇列將其訊息自動轉送至單一佇列，而接收端應用程式將從中取用訊息。 您可以使用這個機制來達成安全性、控制流程，並在每個訊息發佈者之間隔離儲存體。
• 儲存體佇列支援更新訊息內容。 您可以使用這項功能，將狀態資訊和累加進度更新保存至訊息中，以便從最後已知的檢查點處理訊息，而不用從頭開始處理。 使用服務匯流排佇列時，您可以透過使用訊息工作階段來實現相同案例。 如需詳細資訊，請參閱訊息工作階段狀態。
• 服務匯流排佇列支援無效信件處理。 這可用於隔離出符合下列條件的訊息：
  • 接收應用程式無法成功處理訊息
  • 訊息因為存留時間 (TTL) 屬性過期而無法到達其目的地。 TTL 值會指定訊息保留在佇列中的時間長度。 在服務匯流排中，當 TTL 期限到期時，訊息將會移至稱為 $DeadLetterQueue 的特殊佇列。
• 為了在儲存體佇列中找出「有害」訊息，應用程式會在清除佇列中的訊息時，檢查訊息的 DequeueCount 屬性。 如果 DequeueCount 大於給定的臨界值，應用程式就會將訊息移至應用程式定義的「無效信件」佇列。
• 儲存體佇列可讓您取得針對佇列執行的所有交易詳細記錄，以及彙總的計量資料。 這兩個選項有助於偵錯和了解應用程式的儲存體佇列使用狀況。 也有助於對您的應用程式進行效能微調，以及降低使用佇列的成本。
• 服務匯流排支援的訊息工作階段可讓屬於邏輯群組的訊息與接收者相關聯。 此功能會在訊息與其各自的接收者之間建立類似工作階段的親和性。 您可以設定訊息上的 session ID 屬性，以在服務匯流排中啟用這項進階功能。 然後，接收者就可以接聽特定的工作階段 ID，並且接收共用指定之工作階段識別項的訊息。
• 服務匯流排佇列所支援的重複偵測功能會根據 message ID 屬性的值，自動移除傳送至佇列或主題的重複訊息。

容量和配額

本節將從可能適用的容量和配額觀點來比較儲存體佇列和服務匯流排佇列。

其他資訊

• 服務匯流排會強制執行佇列大小限制。 建立佇列時需指定佇列大小上限。 上限可以介於 1 GB 與 80 TB 之間。 如果佇列的大小達到此上限，則會拒絕其他傳入訊息，且呼叫端會收到例外狀況。 如需服務匯流排中配額的詳細資訊，請參閱服務匯流排配額。
• 在標準傳訊層中，您可以建立 1 (預設值)、2、3、4 或 5 GB 大小的服務匯流排佇列和主題。 在標準層中啟用資料分割時，服務匯流排會根據您所指定的大小，以每 GB 建立 16 個複本 (16 個分割區)。 因此，如果您建立 5 GB 大小的佇列，每 GB 有 16 個資料分割，則佇列大小上限會變成 (5 * 16) = 80 GB。 您可以在 Azure 入口網站中查看分割的佇列或主題項目的大小上限。
• 使用儲存體佇列時，如果訊息內容不是 XML 安全內容，則必須經過 Base64 編碼。 如果您對訊息進行 Base64 編碼，使用者承載最多可為 48 KB，而非 64 KB。
• 使用服務匯流排佇列時，儲存在佇列中的每個訊息都包含兩個部分：標頭和主體。 訊息大小總計不能超過服務層級所支援的訊息大小上限。
• 當用戶端透過 TCP 通訊協定與服務匯流排佇列通訊時，單一服務匯流排佇列的並行連接數目上限會限制為 100。 這個數目是在傳送者和接收者之間共用的。 如果達到這個配額，其他連接的要求將會遭到拒絕，而且呼叫端程式碼將會收到例外狀況。 這項限制不會加諸於使用 REST API 連接至佇列的用戶端。
• 如果您的單一服務匯流排服務命名空間需要超過 10,000 個佇列，您可以連絡 Azure 支援小組並要求增加。 若要讓服務匯流排擴充到超過 10,000 個佇列，您也可以使用 Azure 入口網站來建立其他命名空間。

管理和作業

本節將比較儲存體佇列和服務匯流排佇列所提供的管理功能。

其他資訊

• 儲存體佇列支援可套用至佇列描述的任意屬性，格式為名稱/值組。
• 這兩種佇列技術都提供不需要鎖定訊息即可查看訊息的功能，這項功能在實作佇列總管/瀏覽器工具時很有用。
• 相較於透過 HTTP 的 REST，服務匯流排的 .NET 代理傳訊 API 會使用全雙工 TCP 連接來提升效能，而且可支援 AMQP 1.0 標準通訊協定。
• 儲存體佇列名稱長度可以是 3-63 個字元，而且可以包含小寫字母、數字和連字號。 如需詳細資訊，請參閱為佇列和中繼資料命名。
• 服務匯流排佇列名稱長度最多 260 個字元，而且命名規則的限制較少。 服務匯流排佇列名稱可以包含字母、數字、句號、連字號和底線。

驗證和授權

本節將討論儲存體佇列和服務匯流排佇列所支援的驗證和授權功能。

其他資訊

• 對這兩種佇列技術提出的每項要求都必須經過驗證。 不支援具有匿名存取的公用佇列。
• 透過共用存取簽章 (SAS) 驗證，您可以在佇列上建立共用存取授權規則，讓使用者擁有唯寫、唯讀或完整存取權。 如需詳細資訊，請參閱 Azure 儲存體 - SAS 驗證和 Azure 服務匯流排 - SAS 驗證。
• 這兩個佇列都支援使用 Microsoft Entra ID 授權存取。 使用由 Microsoft Entra ID 傳回的 OAuth 2.0 權杖來授權使用者或應用程式，可透過共用存取簽章 (SAS) 提供卓越的安全性與易用性。 透過 Microsoft Entra ID 即不需要冒著潛在安全性弱點的風險，將權杖儲存在程式碼中。 如需詳細資訊，請參閱 Azure 儲存體 - Microsoft Entra 驗證和 Azure 服務匯流排 - Microsoft Entra 驗證。

推論

透過深入了解這兩種技術，您可以更妥善決定要使用哪種佇列技術以及使用時機。 關於何時使用儲存體佇列或服務匯流排佇列的決定當然取決於許多因素。 這些因素主要取決於應用程式及其架構的個別需求。

您可能基於如下原因而偏好選擇儲存體佇列：

• 您的應用程式已在使用 Microsoft Azure 的核心功能
• 需要服務之間的基本通訊和傳訊
• 需要大小可超過 80 GB 的佇列

服務匯流排佇列提供許多進階功能，例如下列功能。 因此，如果您要建置混合式應用程式，或應用程式需要這些功能，則這些佇列可能是適合的選擇。

• 工作階段
• 交易
• 重複資料偵測
• 自動處理無效信件
• 長期發佈和訂閱功能

下一步

下列文章提供有關使用儲存體佇列或服務匯流排佇列的更多指引和資訊。

• 開始使用服務匯流排佇列
• 如何使用佇列儲存體服務
• 使用服務匯流排代理傳訊的效能改進最佳作法