匯出 (0) 列印
全部展開

服務匯流排佇列和主題的容量規劃

作者:Valery Mizonov 和 Ralph Squillace

本主題描述的是:

  • Windows Azure 佇列與 Windows Azure Service Bus 佇列和主題之間通常很重要的佇列大小限制差異

  • 如何在您想要利用服務匯流排佇列和主題功能時推估正確的服務匯流排佇列容量

  • 使用不同大小的訊息來執行測試,以便概略了解可在服務匯流排佇列或主題中放入該大小的訊息數目

Windows Azure Service Bus 中的佇列和主題大小限制

Windows Azure 佇列和服務匯流排佇列都是佇列式存取儲存體的實作,但是每種佇列的功能集都稍有不同,表示您可以根據特定應用程式的需求選擇其中一種佇列。例如,服務匯流排具有主題和訂閱,這在商務通知案例中通常是很重要的 pub-sub 實作。此外,Windows Azure 佇列可以儲存多達 100 TB 的資料,而服務匯流排佇列目前限制為 5 GB。

下面將顯示兩個主要差異區域 - 訊息大小上限和佇列大小上限:

 

比較 Windows Azure 佇列 服務匯流排佇列

訊息大小上限

64 KB

注意:這包括大約 25% 的 base64 編碼負擔。

256 KB

注意:這包括標頭和主體,其中標頭大小上限是 64 KB。

佇列大小上限

100 TB

注意:大小上限是在儲存體帳戶層級限制的。

1、2、3、4 或 5 GB

大小是在建立佇列或主題時定義的。

最後一項差異 (服務匯流排的 5 GB 佇列和主題大小限制,相較於 Windows Azure 佇列的 100 TB 限制) 可能相當重要,因為這表示如果您想要使用無效信件處理、主題和訂閱、規則或動作等服務匯流排功能,就必須事先評估應用程式所需的服務匯流排佇列或主題容量,才能建置可靠的應用程式。根據訊息大小、訊息標頭的大小、任何自訂訊息屬性的大小以及這些訊息加入佇列或傳送至主題的速度,非常活躍的應用程式可能會輕易地建立具有 5 GB 資料的佇列或主題。

最後,使用服務匯流排佇列時,您可以在建立佇列時確立佇列大小。一旦建立佇列之後,您就無法調整佇列的大小。此外,Windows Azure 佇列能夠存取較大的儲存空間,因此您幾乎不需要考慮提高 Windows Azure 佇列的大小。

當佇列或主題超過其設定的容量時,將訊息加入佇列的後續要求就會產生 Microsoft.ServiceBus.Messaging.QuotaExceededException 例外狀況。您的應用程式應該針對這種特定例外狀況類型提供適當的處理。例如,其中一種方法是暫時暫停佇列或主題的訊息傳遞,讓取用者有足夠的時間處理積存,然後再繼續進行訊息發行。

此外,請務必記住,服務匯流排佇列中的訊息是由兩個部分組成:標頭和主體。整個訊息 (標頭 + 主體) 的大小總計不得超過 256 KB。服務匯流排代理訊息應用程式開發介面會使用二進位 XML 序列化 (而非文字 XML),以便減少序列化裝載的輸出大小,而且雖然這種格式可以儲存稍微超過 256 KB 的訊息,不過您必須測試應用程式所呈現的大小縮減程度。

計算服務匯流排佇列和主題的容量

讓我們來看看計算訊息大小的基本演算法,以及您的應用程式可能需要的服務匯流排佇列或主題種類。

空白訊息的主體大小為 1024 個位元組,而預設標頭大小為 156 個位元組。加入其他項目之後,沒有自訂標頭或屬性且訊息主體為空白的訊息大小總計便合計為 1635 個位元組。

下列公式可用來估計指定之訊息數目可能產生的大小需求:

訊息數目 * (訊息主體大小 + 訊息標頭大小)

若要判斷主體大小,請使用 BrokeredMessage.Size 屬性。標頭大小可能比較棘手,因此它會取決於您所需要的精確度。最精確的方法是傳送訊息 (或測試訊息,如果您需要在傳送多個訊息之前了解這項資訊的話),然後使用 NamespaceManager.GetQueue (或 NamespaceManager.GetTopic) 方法來查詢佇列中繼資料,並且使用 SizeInBytes 屬性 (屬於 QueueDescriptionTopicDescription 物件) 來判斷增加的標頭大小。

主題大小需要稍微不同的演算法。若要判斷給定訊息數目在主題中耗用的空間,其公式如下:

訊息數目 * (訊息主體大小 + (訊息標頭大小 * 訂閱數目))

請注意,標頭大小會乘以主題的訂閱數目,這表示如果任何自訂標頭加入至您的主題訊息,主題大小將會依照訂閱數目增加。

例如,如果您的預設訊息包含 200 個訂閱,就會產生 32 KB 的主題大小。不過,如果您將標頭大小提高為 600 個位元組,主題大小就會變成 120 KB。最後,如果您加入來自每個訂閱接收者的 ACK 訊息,大小就會增加相當多。如果單一訊息包含一個 600 位元組的標頭搭配 200 個訂閱,並加入 200 個 ACK 訊息 (每個訂閱一個訊息),就會產生 568,635 個位元組。請務必事先考量這點。

驗證容量近似值

在推估單一服務匯流排佇列可以存放的訊息數目時,您可以將下列資料列入考量。這項資料是由自訂公用程式所擷取,以便使用不同的訊息大小選項來判斷佇列容量。

 

範例訊息大小 1 GB 佇列 2 GB 佇列 3 GB 佇列 4 GB 佇列 5 GB 佇列

1 KB

1,041,790

2,059,920

3,128,550

4,186,400

5,238,750

10 KB

102,996

208,358

312,537

416,716

520,895

50 KB

20,857

41,792

62,507

83,343

104,179

100 KB

10,466

20,836

31,254

41,672

52,090

250 KB

4,191

8,334

12,501

16,669

20,836

為了排除二進位 XML 序列化對於測試結果可能造成的影響,所有範例訊息都使用以隨機值填入個別大小的位元組陣列進行初始化。

另請參閱


建置日期:

2013-10-23

社群新增項目

顯示:
© 2014 Microsoft