儲存體佇列和服務匯流排佇列 - 異同比較
本文將分析 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) (使用訊息工作階段) |
| 傳遞保證 | 至少一次 | 至少一次 (使用 PeekLock 接收模式。這是預設值) 最多一次 (使用 ReceiveAndDelete 接收模式) 深入了解各種接收模式 |
| 不可部分完成作業支援 | No | Yes |
| 接收行為 | 非封鎖 (如果找不到新的訊息，便立即完成) |
使用或不使用逾時封鎖 (提供長期輪詢，或稱為 Comet 技術) 非封鎖 (僅使用 .NET 受控 API) |
| 推送型 API | No | Yes 我們的 .NET、JAVA、JavaScript 和 Go SDK 提供推送樣式 API。 |
| 接收模式 | 查看與租用 | 查看與鎖定 接收與刪除 |
| 獨佔存取模式 | 租用型 | 鎖定型 |
| 租用/鎖定持續時間 | 30 秒 (預設值) 7 天 (上限) (您可以使用 UpdateMessage API 更新或釋放訊息租用。) |
30 秒 (預設值) 您可以為訊息鎖定每次手動更新相同的鎖定持續時間，或使用自動鎖定更新功能，讓用戶端為您管理鎖定更新。 |
| 租用/鎖定精確度 | 訊息層級 每個訊息都可以具有不同的逾時值，您稍後可以在處理訊息時，視需要使用 UpdateMessage API 更新這個逾時值。 |
佇列層級 (每個佇列都有套用至其所有訊息的鎖定精確度，但鎖定可以依照上一個資料列所述方式更新) |
| 批次接收 | Yes (在擷取訊息時明確指定訊息計數，最多 32 個訊息) |
Yes (隱含啟用預先擷取屬性或透過使用交易明確啟用) |
| 批次傳送 | No | Yes (使用交易或用戶端批次處理) |
其他資訊
- 儲存體佇列中的訊息通常是先進先出，但有時也不按順序。 例如，當用戶端應用程式在處理訊息時當機，而導致訊息的可見度逾時持續時間到期時。 當可視性逾時到期時，訊息會再次出現在佇列上，以便其他工作者清除佇列中的訊息。 此時，佇列中可能放入新出現的訊息，等待再次從佇列中清除。
- 服務匯流排佇列中的保證 FIFO 模式需要使用訊息工作階段。 如果應用程式在處理以查看與鎖定模式所接收的訊息時損毀，下一次佇列接收者接受訊息工作階段時，將會在工作階段的鎖定持續時間到期之後，從失敗的訊息開始處理。
- 儲存體佇列的設計目的是支援標準佇列案例，例如下列佇列案例：
- 將應用程式元件分離，以提高可延展性和失敗的容錯度
- 負載調節
- 建置流程工作流程。
- 若要避免有關訊息處理服務匯流排會話內容中的訊息處理不一致，可使用工作階段狀態來儲存應用程式相對於處理工作階段訊息順序的進度，以及使用有關解決已接收訊息和更新工作階段狀態的交易。 這種一致性功能有時會在其他廠商的產品中標示為「僅處理一次」。 任何交易失敗都顯然會導致訊息重新傳遞，因此這種說法並不完全適合。
- 儲存體佇列提供跨佇列、資料表和 BLOB 之統一且一致的程式設計模型，適合開發人員和營運團隊使用。
- 服務匯流排佇列支援在單一佇列內容中進行本機交易。
- 服務匯流排所支援的「接收與刪除」模式可讓您降低訊息作業計數 (以及關聯的成本)，但是也會降低傳遞保證。
- 儲存體佇列可讓租用延長訊息的租用。 此功能可讓背景工作處理序維持短期的訊息租用。 因此，如果某個背景工作角色損毀，就可以由另一個背景工作角色快速地重新處理訊息。 此外，如果背景工作角色需要的處理時間超過目前的租用時間，也可以延長訊息的租用。
- 儲存體佇列提供您可以在將訊息加入佇列或從佇列中清除訊息時設定的可視性逾時。 此外，您可以在執行階段使用不同的租用值來更新訊息，並且在相同佇列的訊息之間更新不同的值。 服務匯流排鎖定逾時會在佇列中繼資料中定義。 然而，您可以為訊息鎖定手動更新預先定義的鎖定持續時間，或使用自動鎖定更新功能，讓用戶端為您管理鎖定更新。
- 在服務匯流排佇列中，封鎖接收作業的最大逾時值是 24 天。 但是，REST 架構的最大逾時值為 55 秒。
- 服務匯流排所提供的用戶端批次允許佇列用戶端將多個訊息批次處理成單一傳送作業。 批次處理僅適用於非同步傳送作業。
- 儲存體佇列的 200 TB 上限 (當您虛擬化帳戶時則更多) 和無限佇列等功能，使它成為 SaaS 提供者的理想平台。
- 儲存體佇列提供彈性、高效能的委派存取控制機制。
進階功能
本節將比較儲存體佇列和服務匯流排佇列所提供的進階功能。
| 比較準則 | 儲存體佇列 | 服務匯流排佇列 |
|---|---|---|
| 排定的傳遞 | Yes | Yes |
| 自動處理無效信件 | No | Yes |
| 增加佇列存留時間值 | Yes (經由可視性逾時的就地更新) |
Yes (由專用 API 函式提供) |
| 有害訊息支援 | Yes | Yes |
| 就地更新 | Yes | Yes |
| 伺服器端交易記錄 | 是 | No |
| 儲存體計量 | Yes 「分鐘計量」會提供可用性、TPS、API 呼叫計數、錯誤計數等項目的即時計量。 這些數據會在每分鐘即時彙總，並在生產環境發生的幾分鐘後進行報告。 如需詳細資訊，請參閱關於儲存體分析度量。 |
Yes 如需 Azure 服務匯流排所支援計量的相關資訊，請參閱訊息計量。 |
| 狀態管理 | No | 是 (Active、Disabled、SendDisabled、ReceiveDisabled。如需這些狀態的詳細資料，請參閱佇列狀態) |
| 訊息自動轉送 | No | Yes |
| 清除佇列函式 | Yes | 是 |
| 訊息群組 | No | Yes (使用傳訊工作階段) |
| 每個訊息群組的應用程式狀態 | No | Yes |
| 重複資料偵測 | No | Yes (可在傳送者端設定) |
| 瀏覽訊息群組 | No | Yes |
| 依 ID 擷取訊息工作階段 | No | Yes |
其他資訊
- 這兩種佇列技術都可讓訊息排定在稍後傳遞。
- 佇列自動轉送可讓數以千計的佇列將其訊息自動轉送至單一佇列，而接收端應用程式將從中取用訊息。 您可以使用這個機制來達成安全性、控制流程，並在每個訊息發佈者之間隔離儲存體。
- 儲存體佇列支援更新訊息內容。 您可以使用這項功能，將狀態資訊和累加進度更新保存至訊息中，以便從最後已知的檢查點處理訊息，而不用從頭開始處理。 使用服務匯流排佇列時，您可以透過使用訊息工作階段來實現相同案例。 如需詳細資訊，請參閱訊息工作階段狀態。
- 服務匯流排佇列支援無效信件處理。 這可用於隔離出符合下列條件的訊息：
- 接收應用程式無法成功處理訊息
- 訊息因為存留時間 (TTL) 屬性過期而無法到達其目的地。 TTL 值會指定訊息保留在佇列中的時間長度。 在服務匯流排中，當 TTL 期限到期時，訊息將會移至稱為 $DeadLetterQueue 的特殊佇列。
- 為了在儲存體佇列中找出「有害」訊息，應用程式會在清除佇列中的訊息時，檢查訊息的 DequeueCount 屬性。 如果 DequeueCount 大於給定的臨界值，應用程式就會將訊息移至應用程式定義的「無效信件」佇列。
- 儲存體佇列可讓您取得針對佇列執行的所有交易詳細記錄，以及彙總的計量資料。 這兩個選項有助於偵錯和了解應用程式的儲存體佇列使用狀況。 也有助於對您的應用程式進行效能微調，以及降低使用佇列的成本。
- 服務匯流排支援的訊息工作階段可讓屬於邏輯群組的訊息與接收者相關聯。 此功能會在訊息與其各自的接收者之間建立類似工作階段的親和性。 您可以設定訊息上的 session ID 屬性，以在服務匯流排中啟用這項進階功能。 然後，接收者就可以接聽特定的工作階段 ID，並且接收共用指定之工作階段識別項的訊息。
- 服務匯流排佇列所支援的重複偵測功能會根據 message ID 屬性的值，自動移除傳送至佇列或主題的重複訊息。
容量和配額
本節將從可能適用的容量和配額觀點來比較儲存體佇列和服務匯流排佇列。
| 比較準則 | 儲存體佇列 | 服務匯流排佇列 |
|---|---|---|
| 佇列大小上限 | 500 TB (限制為單一儲存體帳戶容量) |
1 GB 到 80 GB （具有數據分割的進階 SKU 或標準 SKU） |
| 郵件大小上限 | 64 KB (使用 Base 64 編碼時則為 48 KB) Azure 可以結合佇列和 Blob 來支援大型訊息，因此您最多可以將 200 GB 的單一項目加入佇列。 |
256 KB、1 MB 或 100 MB (包括標頭和主體，標頭大小上限：64 KB)。 取決於服務層級。 |
| 訊息 TTL 上限 | 無限 (API 2017-07-27 版或更新版本) | TimeSpan.MaxValue |
| 佇列數目上限 | 不限定 | 10,000 （標準 SKU） 1000 / 傳訊單位 （進階 SKU） (每一服務命名空間) |
| 並行用戶端數目上限 | 不限定 | 5,000 |
其他資訊
- 服務匯流排會強制執行佇列大小限制。 建立佇列時需指定佇列大小上限。 上限可以介於 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 連接至佇列的用戶端。
- 若要使用 服務匯流排 標準 SKU 或具有 服務匯流排 Premium SKU 的 1000 個佇列/傳訊單位來調整超過 10,000 個佇列，您也可以使用 Azure 入口網站 建立其他命名空間。
管理和作業
本節將比較儲存體佇列和服務匯流排佇列所提供的管理功能。
| 比較準則 | 儲存體佇列 | 服務匯流排佇列 |
|---|---|---|
| 管理通訊協定 | REST 透過 HTTP/HTTPS | REST 透過 HTTPS |
| 執行階段通訊協定 | REST 透過 HTTP/HTTPS | REST 透過 HTTPS AMQP 1.0 標準 (具有 TLS 的 TCP) |
| .NET API | Yes (.NET 儲存體用戶端 API) |
Yes (.NET 服務匯流排 API) |
| 原生 C++ | Yes | Yes |
| Java API | Yes | Yes |
| PHP API | Yes | Yes |
| Node.js API | Yes | Yes |
| 任意中繼資料支援 | 是 | No |
| 佇列命名規則 | 長度最多 63 個字元 (佇列名稱的字母必須是小寫。) |
長度最多 260 個字元 (佇列路徑和名稱不區分大小寫。) |
| 取得佇列長度函式 | Yes (如果訊息過了 TTL 而到期卻未遭刪除，則為近似值。) |
Yes (精確的時間點值。) |
| 查看函式 | Yes | Yes |
其他資訊
- 儲存體佇列支援可套用至佇列描述的任意屬性，格式為名稱/值組。
- 這兩種佇列技術都提供不需要鎖定訊息即可查看訊息的功能，這項功能在實作佇列總管/瀏覽器工具時很有用。
- 相較於透過 HTTP 的 REST，服務匯流排的 .NET 代理傳訊 API 會使用全雙工 TCP 連接來提升效能，而且可支援 AMQP 1.0 標準通訊協定。
- 儲存體佇列名稱長度可以是 3-63 個字元，而且可以包含小寫字母、數字和連字號。 如需詳細資訊，請參閱為佇列和中繼資料命名。
- 服務匯流排佇列名稱長度最多 260 個字元，而且命名規則的限制較少。 服務匯流排佇列名稱可以包含字母、數字、句號、連字號和底線。
驗證和授權
本節將討論儲存體佇列和服務匯流排佇列所支援的驗證和授權功能。
| 比較準則 | 儲存體佇列 | 服務匯流排佇列 |
|---|---|---|
| 驗證 | 對稱金鑰和角色型存取控制 (RBAC) | 對稱金鑰和角色型存取控制 (RBAC) |
| 識別提供者同盟 | Yes | Yes |
其他資訊
- 對這兩種佇列技術提出的每項要求都必須經過驗證。 不支援具有匿名存取的公用佇列。
- 透過共用存取簽章 (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 的佇列
服務匯流排佇列提供許多進階功能，例如下列功能。 因此，如果您要建置混合式應用程式，或應用程式需要這些功能，則這些佇列可能是適合的選擇。
下一步
下列文章提供有關使用儲存體佇列或服務匯流排佇列的更多指引和資訊。