Azure Messaging-ServiceBus Messaging消息隊列技術系列8-服務總線配額

上篇博文中我們介紹了Azure ServiceBus Messaging的消息事務機制：

Azure Messaging-ServiceBus Messaging消息隊列技術系列7-消息事務（2017-03-30 22:12）

本文中我們介紹一下ServiceBus Messaging的一些配額，或者說使用說明和限制。原文請參考：

https://docs.microsoft.com/zh-cn/azure/service-bus-messaging/service-bus-quotas

我們着重介紹在實際消息應用開發時，會用到的、需要重點關注的幾個配額選項。

1. 命名空間上限：即每個 Azure 訂閱的基本/标準命名空間數上限：100，

2. 隊列/主題大小，即我們使用的Queue或者Topic的容量，白話一點就是消息隊列能承載多少消息，我們在實際應用時，一定要做一個評估，評估有兩個方面，一個是我們業務高峰期會有多少消息，即消息的QPS，另一個是，未來1~2年，随着業務規模的擴張，現有的Queue/Topic的容量是否滿足我們未來發展的要求。

    Azure ServiceBus Messaging中已經顯式的說明：系統将拒絕傳入消息，且調用代碼将收到異常。

    隊列/主題的大小，在聲明時指定，Azure ServiceBus Messaging提供了1、2、3、4 或 5 GB選項，同時，如果已啟用分區，最大隊列/主題大小是 80 GB。

    相信這個大小是Azure已經評估過的，大多數場景和規模都可以滿足。

3. 并發連接配接數，并發連接配接數，Azure在命名控制和隊列、主題、訂閱這個層面統一做了限制。其中：

   命名空間上的并發連接配接數：NetMessaging：1,000，AMQP：5,000

   隊列/主題/訂閱實體上的并發連接配接數：受每個命名空間的并發連接配接限制的限制；

   隊列/主題/訂閱實體上的并發接收請求數：5,000

   當超過并發連接配接數時：系統将拒絕後續的附加連接配接請求，且調用代碼将收到異常。 同時，REST 操作不計入并發 TCP 連接配接數。

   這點大家要注意！

4. 每個服務命名空間的主題/隊列數：即我們在每個服務的Namespace上可以建立多少個隊列或者主題，這項配額是10000，服務命名空間中主題和隊列的數目之和必須小于或等

   于 10,000。如果超過這個配額：将拒絕後續的在服務命名空間中建立新主題或隊列的請求。 是以，如果是通過 Azure 門戶配置的，将生成錯誤消息。 如果是通過管理 API 調

   用的，調用代碼将收到異常。

   這個隊列數和主題數限制對于大規模消息應用的開發來說是有影響的，我們如果使用多個Namespace就可以橫向擴充隊列和主題的個數，這有點上業界主流的Sharding機制。贊

   一個。

5. 任一消息實體路徑的最大大小：隊列或主題，即消息隊列或者主題名稱的長度是：260個字元

6. 隊列/主題/訂閱實體的消息大小：這個選項對我們來說非常重要，直接影響我們構造消息的大小。最大消息大小：256KB（标準層）/1MB（進階層）。 注意由于系統開銷問

題，此限制通常略小一點，最大标頭（消息頭）大小：64KB，屬性包（消息屬性）中的最大标頭屬性數：byte/int.MaxValue，屬性包中屬性的最大大小：沒有明确的限制。 受最

大标頭大小限制。

7. 隊列/主題/訂閱實體的消息屬性大小：每個屬性的最大消息屬性大小為 32K。 所有屬性的累計大小不得超過 64K。如果超過這個配額：将生成 SerializationException 異

常。

8. 每個主題的訂閱數：即每個Topic可以有多少訂閱，2000，如果超過這個配額：

   Azure将拒絕後續的為主題建立附加訂閱的請求。 是以，如果是通過門戶配置的，将顯示錯誤消息。 如果是通過管理 API 調用的，調用代碼将收到異常。

周國慶

2017/4/11