事件中樞的縮放
有兩個因素會影響事件中樞的縮放。
- 輸送量單位 (標準層) 或處理單位 (進階層)
- 資料分割
輸送量單位
事件中樞的輸送量容量受「輸送量單位」所控制。 輸送量單位是預先購買的容量單位。 單一輸送量單位可讓您：
- 輸入：每秒最多 1 MB 或 1000 個事件 (以先達到者為準)。
- 輸出：最高每秒 2 MB 或每秒 4096 個事件。
超出已購買輸送量單位的容量，輸入會受到節流，而事件中樞會 擲回 EventHubsException （ServiceBusy 的 Reason 值）。 輸出不會產生節流例外狀況，但仍受限於所購買輸送量單位的容量。 如果您收到發佈速率例外狀況，或輸出速率低於預期，請務必檢查您為命名空間所購買的輸送量單位數目。 在 Azure 入口網站中，您可以在命名空間的 [縮放] 頁面管理輸送量單位。 您也可以使用事件中樞 API 以程式設計方式管理輸送量單位。
輸送量單位是預先購買制且以每小時計費。 一經購買，您至少必須支付一個小時的輸送量單位費用。 最多可以為一個事件中樞命名空間購買 40 個輸送量單位，讓該命名空間中的所有事件中樞共用。
「事件中樞」的「自動擴充」功能會自動增加輸送量單位數以進行相應增加，進而符合使用量需求。 增加輸送量單位可避免發生節流情況，其中：
- 資料輸入速率會超出所設定的輸送量單位。
- 資料輸出要求速率會超出所設定的輸送量單位。
「事件中樞」服務可在負載超過最低閾值時增加輸送量，不會有任何要求因為發生 ServerBusy 錯誤而失敗。
如需自動擴充功能的詳細資訊，請參閱自動縮放輸送量單位 (部分機器翻譯)。
處理單位
事件中樞進階版可在受控的多租用戶 PaaS 環境中，提供優異的效能和更好的隔離。 進階層中的資源會在 CPU 和記憶體層級上區隔，讓每個租用戶工作負載能夠獨立執行。 此資源容器稱為處理單位 (PU)。 您可以為每個事件中樞 Premium 命名空間購買 1、2、4、6、8、10、12 或 16 個處理單位。
可使用處理器擷取和串流的用量，會因多種不同因素而異。包括您的產生者、取用者、擷取和處理的頻率等。
例如，事件中樞進階版命名空間具有 1 個 PU 和 1 個事件中樞 (100 個分割區)，大約可同時為 AMQP 或 Kafka 工作負載提供約 5-10 MB/秒的輸入和 10-20 MB/秒輸出的核心容量。
若要了解如何設定進階層命名空間的 PU，請參閱設定處理單位。
注意
若要深入了解配額和限制，請參閱 Azure 事件中樞 - 配額和限制。
資料分割
事件中樞將傳送至事件中樞的事件序列組織成一或多個分割區。 當較新的事件送達時，系統會將它們加入序列的結尾。
分割區可以視為認可記錄。 分割區會儲存包含下列資訊的事件資料：
- 事件的本文
- 描述事件的使用者定義屬性包
- 中繼資料，例如分割區中的位移、資料流序列中的數字
- 服務端接受的時間戳記
使用分割區的優點
設計出事件中樞是為了協助處理大量的事件，而分割可從兩個方面提供協助：
- 即使事件中樞是 PaaS 服務，仍須面對其背後真正的現實。 為了維護記錄來維持事件的順序，這些事件必須一起保存在基礎儲存體及其複本中，這就形成這類記錄的輸送量上限。 資料分割可讓相同的事件中樞使用多個平行記錄，可用的原始輸入-輸出 (IO) 輸送量容量因此倍增。
- 您自己的應用程式必須來得及處理傳入事件中樞的事件量。 這可能會非常複雜，因此需要大量已擴增的平行處理容量。 單一流程處理事件的容量有限，因此需要多個流程。 分割區可讓解決方案供給這些流程，還可確保每個事件都有明確的處理擁有者。
資料分割數目
分割區數目是在建立事件中樞時指定。 必須介於 1 與每個定價層允許的最大分割區計數之間。 如需每一層的分割計數限制，請參閱這篇文章。
針對該特定的事件中樞，建議至少選擇您預期在應用程式尖峰負載期間所需的分割區數目。 對於進階和專用層以外的階層，您無法在建立事件中樞之後變更分割區計數。 針對進階或專用層中的事件中樞，您可以在建立後增加分割區計數，但無法減少分割區計數。 當分割區與分割區索引鍵發生變化時，資料流在分割區的分佈也會隨之變更，因此，如果事件的相對順序在您的應用程式中很重要，則請試著盡量避免這類變更。
將分割區數量設定為所允許的最大值雖然是誘人的方式，但請務必記住，事件串流必須有良好的結構，才能確實地利用好多個分割區。 如果您需要讓所有事件或只在少量子串流以絕對順序進行保留，則不一定能夠利用許多個分割區。 此外，多個分割區會讓處理層面變得更複雜。
定價與事件中樞有多少個分割區無關。 主要取決於命名空間或專用叢集的定價單位數目 (標準層的輸送量單位 (TU)、進階層的處理單位 (PU)，以及專用層的容量單位 (CU))。 例如，當命名空間設定為 1 TU 容量時，不論標準層的事件中樞有 32 個分割區還是 1 個分割區，成本都一樣。 此外，您可以縮放命名空間上的 TU 或 PU，或專用叢集的 CU，與分割區計數無關。
因為分割區是一種資料組織機制，可讓您以平行方式發佈及取用資料。 建議您平衡縮放單位 (標準層的輸送量單位、進階層的處理單位，或專用層的容量單位) 和分割區，以實現最佳縮放。 一般而言，我們建議每個分割區的最大輸送量為 1 MB/秒。 因此，計算分割區數目的經驗法則，是將預期的輸送量上限除以 1 MB/秒。 例如，如果您的使用案例需要 20 MB/秒，建議您選擇至少 20 個分割區，以達到最佳輸送量。
不過，如果在您的模型中，應用程式對特定分割區具有同質性，則提高分割區數目並無益處。 如需詳細資訊，請參閱可用性和一致性。
將事件對應至分割區
您可以使用資料分割索引鍵，將內送事件對映至特定的資料分割來組織資料。 資料分割索引鍵是由傳送者提供的值。系統會將它傳遞到事件中樞， 然後透過靜態雜湊函式加以處理，而建立資料分割指派。 如果您在發佈事件時未指定資料分割索引鍵，系統會使用循環配置資源指派。
事件發佈行者只會知道資料分割索引鍵，不會知道事件發佈的目的地資料分割。 索引鍵和資料分割脫鉤的這種機制，讓傳送者不需要知道太多有關下游處理的細節。 每部裝置或每位使用者的唯一身分識別能成為有效的資料分割索引鍵，不過像地理位置之類的其他屬性也能用來將相關事件歸納成一個資料分割。
指定分割區索引鍵可讓相關事件按照其抵達時的確切順序，一起保存在相同的分割區中。 分割區索引鍵是衍生自應用程式內容的某個字串，可識別事件的相互關係。 分割區索引鍵所識別的一連串事件便是串流。 分割區是許多這類串流的多工記錄存放區。
注意
雖然可以直接將事件傳送至分割區，但不建議如此，尤其當高可用性很重要時。 這會使事件中樞的可用性降到分割區層級。 如需詳細資訊，請參閱可用性和一致性。
相關內容
您可以造訪下列連結以深入了解事件中樞︰