Azure 事件中樞的功能與術語
Azure 事件中樞是可調整的事件處理服務，它會擷取和處理大量的事件和資料，具有低延遲和高可靠性。 如需服務的高階概觀，請參閱何謂事件中樞？。
這篇文章是根據概觀中的資訊建置，並且提供有關事件中樞元件和功能的技術和實作詳細資料。
Namespace
事件中樞命名空間是事件中樞 (在 Kafka 用語中叫做主題) 的管理容器。 提供 DNS 整合式網路端點，以及一系列的存取控制和網路整合管理功能，例如 IP 篩選、虛擬網路服務端點，以及 Private Link。
資料分割
事件中樞將傳送至事件中樞的事件序列組織成一或多個分割區。 當較新的事件送達時，系統會將它們加入序列的結尾。
分割區可以視為認可記錄。 分割區會儲存包含下列資訊的事件資料：
- 事件的本文
- 描述事件的使用者定義屬性包
- 中繼資料，例如分割區中的位移、資料流序列中的數字
- 服務端接受的時間戳記
使用分割區的優點
設計出事件中樞是為了協助處理大量的事件，而分割可從兩個方面提供協助：
- 即使事件中樞是 PaaS 服務，仍須面對其背後真正的現實。 為了維護記錄來維持事件的順序，這些事件必須一起保存在基礎儲存體及其複本中，這就形成這類記錄的輸送量上限。 資料分割可讓相同的事件中樞使用多個平行記錄，可用的原始輸入-輸出 (IO) 輸送量容量因此倍增。
- 您自己的應用程式必須來得及處理傳入事件中樞的事件量。 這可能會非常複雜，因此需要大量已擴增的平行處理容量。 單一流程處理事件的容量有限，因此需要多個流程。 分割區可讓解決方案供給這些流程，還可確保每個事件都有明確的處理擁有者。
資料分割數目
分割區數目是在建立事件中樞時指定。 必須介於 1 與每個定價層允許的最大分割區計數之間。 如需每一層的分割計數限制，請參閱這篇文章。
針對該特定的事件中樞，建議至少選擇您預期在應用程式尖峰負載期間所需的分割區數目。 對於進階和專用層以外的階層，您無法在建立事件中樞之後變更分割區計數。 針對進階或專用層中的事件中樞，您可以在建立後增加分割區計數，但無法減少分割區計數。 當分割區與分割區索引鍵發生變化時，資料流在分割區的分佈也會隨之變更，因此，如果事件的相對順序在您的應用程式中很重要，則請試著盡量避免這類變更。
將分割區數量設定為所允許的最大值雖然是誘人的方式，但請務必記住，事件串流必須有良好的結構，才能確實地利用好多個分割區。 如果您需要讓所有事件或只在少量子串流以絕對順序進行保留，則不一定能夠利用許多個分割區。 此外，多個分割區會讓處理層面變得更複雜。
定價與事件中樞有多少個分割區無關。 主要取決於命名空間或專用叢集的定價單位數目 (標準層的輸送量單位 (TU)、進階層的處理單位 (PU)，以及專用層的容量單位 (CU))。 例如，當命名空間設定為 1 TU 容量時，不論標準層的事件中樞有 32 個分割區還是 1 個分割區，成本都一樣。 此外，您可以縮放命名空間上的 TU 或 PU，或專用叢集的 CU，與分割區計數無關。
因為分割區是一種資料組織機制，可讓您以平行方式發佈及取用資料。 建議您平衡縮放單位 (標準層的輸送量單位、進階層的處理單位，或專用層的容量單位) 和分割區，以實現最佳縮放。 一般而言，我們建議每個分割區的最大輸送量為 1 MB/秒。 因此，計算分割區數目的經驗法則，是將預期的輸送量上限除以 1 MB/秒。 例如，如果您的使用案例需要 20 MB/秒，建議您選擇至少 20 個分割區，以達到最佳輸送量。
不過，如果在您的模型中，應用程式對特定分割區具有同質性，則提高分割區數目並無益處。 如需詳細資訊，請參閱可用性和一致性。
將事件對應至分割區
您可以使用資料分割索引鍵，將內送事件對映至特定的資料分割來組織資料。 資料分割索引鍵是由傳送者提供的值。系統會將它傳遞到事件中樞， 然後透過靜態雜湊函式加以處理，而建立資料分割指派。 如果您在發佈事件時未指定資料分割索引鍵，系統會使用循環配置資源指派。
事件發佈行者只會知道資料分割索引鍵，不會知道事件發佈的目的地資料分割。 索引鍵和資料分割脫鉤的這種機制，讓傳送者不需要知道太多有關下游處理的細節。 每部裝置或每位使用者的唯一身分識別能成為有效的資料分割索引鍵，不過像地理位置之類的其他屬性也能用來將相關事件歸納成一個資料分割。
指定分割區索引鍵可讓相關事件按照其抵達時的確切順序，一起保存在相同的分割區中。 分割區索引鍵是衍生自應用程式內容的某個字串，可識別事件的相互關係。 分割區索引鍵所識別的一連串事件便是串流。 分割區是許多這類串流的多工記錄存放區。
注意
雖然可以直接將事件傳送至分割區，但不建議如此，尤其當高可用性很重要時。 這會使事件中樞的可用性降到分割區層級。 如需詳細資訊，請參閱可用性和一致性。
事件發佈者
任何將資料傳送至事件中樞的實體就是「事件發行者」(與「事件產生者」同義)。 事件發行者可以使用 HTTPS、AMQP 1.0 或 Kafka 通訊協定來發佈事件。 事件發行者使用 Microsoft Entra ID 型授權，搭配 OAuth2 發出的 JWT 權杖或事件中樞特定的共用存取簽章 (SAS) 權杖，以取得發佈存取權。
您可以透過 AMQP 1.0、Kafka 通訊協定或 HTTPS 來發佈事件。 事件中樞服務提供 REST API 及 .NET、JAVA、Python、JavaScript 和 Go 用戶端程式庫，將事件發佈至事件中樞。 對於其他執行階段和平台，您可以使用任何 AMQP 1.0 用戶端 (如 Apache Qpid)。
使用 AMQP 或 HTTPS 的選擇因使用案例而異。 除了傳輸層級安全性 (TLS) 或 SSL/TLS 之外，AMQP 還需要建立持續性的雙向通訊端。 AMQP 在初始化工作階段時，網路成本較高，但 HTTPS 需要額外的 TLS 工作負荷來處理每個要求。 針對頻繁的發行者，AMQP 有較高的效能，在搭配非同步發佈程式碼一起使用時，可以達到更低的延遲。
您可以單獨發佈事件，或以批次方式進行。 不論是單一事件或批次，單次發佈的上限為 1 MB。 發佈大於此閾值的事件會遭到拒絕。
縮放事件中樞輸送量是使用分割區和輸送量單位配置。 發行者最好保持不知道事件中樞選定的特定資料分割模型，而僅指定「分割區索引鍵」，用以將相關事件一致地指派給相同分割區。
事件中樞能確保所有共用分割區索引鍵值的事件會儲存在一起，並依抵達順序來傳遞。 如果資料分割索引鍵與發佈者原則搭配使用，發佈者的身分識別與資料分割索引鍵的值必須相符， 否則，系統將發生錯誤。
事件保留
已發佈的事件根據可設定的時效性保留原則，從事件中樞移除。 以下是一些重點：
- 預設值和最短的可能保留期間為 1 小時。 目前，您只能在 Azure 入口網站中，以小時為單位來設定保留期間。 Resource Manager 範本、PowerShell 和 CLI 僅允許以天為單位來設定此屬性。
- 若為事件中樞標準，最長保留期間為 7 天。
- 若為事件中樞進階和專用，最長保留期間為 90 天。
- 如果您變更保留期間，則會套用至所有事件，包括已在事件中樞內的事件。
事件中樞會將事件保留一段已設定好的保留時間，這段時間在所有分割區上都一樣。 達到保留期間時，系統就會自動移除事件。 如果您指定的保留期間是一天 (24 小時)，則在接受事件後，事件會在整整 24 小時內變成無法使用的狀態。 您無法明確地刪除事件。
如果事件需要封存超過允許的保留期間，您可以開啟事件中樞擷取功能，自動將事件儲存在 Azure 儲存體或 Azure Data Lake 中。 如果需要搜尋或分析這類深層封存，您可以輕鬆將封存匯入 Azure Synapse，或其他類似的存放區和分析平台。
事件中樞之所以會根據時間來限制資料保留期限，原因是為了避免大量的過往客戶資料深陷在存放區中，而只用時間戳記編製索引，並只允許循序存取。 此處的架構原理在於，相較於事件中樞或 Kafka 提供的即時事件介面，歷史資料需要更豐富編製索引和更直接的存取。 事件串流引擎不太適合扮演事件來源的資料湖或長期封存角色。
注意
事件中樞是即時事件串流引擎，用意不是取代資料庫和/或作為永久存放區來無限期保存事件資料流。
事件資料流的歷程記錄越深，越需要輔助索引來找出特定資料流的特定歷史片段。 檢查事件裝載和編製索引已超出事件中樞 (或 Apache Kafka) 的功能範圍。 因此，資料庫及特製化分析存放區和引擎 (例如 Azure Data Lake Store、Azure Data Lake Analytics 和 Azure Synapse Analytics) 更適合用來儲存歷史事件。
事件中樞擷取直接與 Azure Blob 儲存體和 Azure Data Lake Storage 整合，而透過該整合，還支援直接讓事件流入 Azure Synapse Analytics。
發佈者原則
事件中樞可讓您透過發佈者 原則更精確地控制事件發佈者。 發佈者原則是為了協助大量獨立事件發佈者而設計的執行階段功能。 有了發佈者原則，當每位發佈者使用下列機制將事件發佈到事件中樞時，都能使用自己的唯一識別碼：
//<my namespace>.servicebus.windows.net/<event hub name>/publishers/<my publisher name>
您不需要事先建立發佈者名稱，不過這些名稱必須符合發佈事件時使用的 SAS 權杖，以確保發佈者身分識別是獨立的。 當您使用發行者原則時，PartitionKey 值必須設定為發行者名稱。 為了正常運作，這些值必須相符。
Capture
事件中樞擷取可讓您自動擷取事件中樞的串流資料，然後儲存到您選擇的 Blob 儲存體帳戶，或 Azure Data Lake Storage 帳戶。 您可以從 Azure 入口網站啟用擷取，然後指定執行擷取的大小下限和時間範圍。 使用事件中樞擷取時，您需要指定自己的 Azure Blob 儲存體帳戶和容器，或 Azure Data Lake Storage 帳戶，其中之一用來儲存擷取的資料。 擷取的資料會以 Apache Avro 格式撰寫。
事件中樞擷取所產生的檔案會有下列 Avro 結構描述︰
注意
當您在 Azure 入口網站中使用無程式碼編輯器時，可以在 Parquet 格式的 Azure Data Lake Storage Gen2 帳戶中擷取事件中樞的串流資料。 如需詳細資訊，請參閱操作說明：以 Parquet 格式從事件中樞擷取資料及教學課程：以 Parquet 格式擷取事件中樞資料，並使用 Azure Synapse Analytics 進行分析。
SAS 權杖
事件中樞使用命名空間和事件中樞層級可用的「共用存取簽章」。 SAS 權杖可自 SAS 金鑰產生，它是經過特定格式編碼的 URL SHA 雜湊。 事件中樞可以使用金鑰 (原則) 的名稱和權杖來重新產生雜湊，藉此驗證傳送者。 一般而言，建立的事件發佈者 SAS 權杖只具備特定事件中樞的傳送權限。 此 SAS 權杖 URL 機制是導入發佈者原則之發佈者識別的基礎。 如需使用 SAS 的詳細資訊，請參閱使用服務匯流排的共用存取簽章驗證。
事件取用者
任何從事件中樞讀取事件資料的實體就稱為「事件取用者」。 所有事件中樞取用者都透過 AMQP 1.0 工作階段連接，而可供取用的事件都透過工作階段傳遞。 用戶端不需要輪詢資料可用性。
取用者群組
事件中樞的發佈/訂閱機制可透過「取用者群組」啟用。 取用者群組是取用者的邏輯群組，可從事件中樞或 Kafka 主題讀取資料。 其可讓多個取用應用程式以自己的步調以及使用自己的位移，獨立讀取事件中樞中的相同串流資料。 其可讓您平行處理訊息的取用，並在多個取用者之間散發工作負載，同時維護每個分割區內的訊息順序。
建議您取用者群組內的分割區上只有一個作用中的接收者。 不過，在某些情況下，每個分割區最多可以使用五個取用者或接收者，其中所有接收者都會取得分割區的所有事件。 如果相同分割區上有多個讀取器，則您會需要處理重複的事件。 您需要在程式碼中加以處理，但這可能不容易。 不過，在某些情況下這是有效的方法。
在串流處理架構中，每個下游應用程式等同於一個取用者群組。 如果您想要將事件資料寫入長期存放區，該存放裝置寫入器應用程式即是取用者群組。 複雜的事件處理可以由另一個獨立的取用者群組來執行。 您只能透過取用者群組來存取資料分割。 事件中樞一定有一個預設取用者群組，您可以為對應的定價層建立高達取用者群組數目上限。
Azure SDK 提供的部分用戶端是智慧型取用者代理程式，可自動管理詳細資料，以確定每個分割區都有單一讀取器，而且確實讀取事件中樞的所有分割區。 這樣可讓程式碼專注於處理從事件中樞讀取的事件，而可以忽略分割區的許多細節。 如需詳細資訊，請參閱連線至分割區。
下列範例顯示取用者群組 URI 慣例：
//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #1>
//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #2>
下圖顯示事件中樞串流處理架構︰
串流位移
「位移」是事件在資料分割內的位置。 您可以將位移視為用戶端指標。 位移是事件的位元組編號。 此位移可讓事件取用者 (讀取器) 在事件串流中指定某個點，以便從該點開始讀取事件。 您可以指定時間戳記或位移值等形式的位移。 取用者需負責將自己的位移值儲存在事件中樞服務之外。 在資料分割內，每個事件都含有一個位移。
檢查點檢查
設立檢查點 是讀取器在資料分割事件序列中標記或認可其位置的程序。 設立檢查點是取用者的責任，這項作業會在取用者群組內依照資料分割來進行。 此責任表示在每個取用者群組內，每個資料分割讀取器必須追蹤自己目前在事件串流中的位置，而當它們認為資料串流完成時，可以通知服務。
如果讀取器與資料分割中斷連線，當它重新連線時，會從該取用者群組中該資料分割最後一個讀取器先前提交的檢查點開始讀取。 當讀取器連線時，它會將此位移傳遞給事件中樞，以指定要開始讀取的位置。 如此一來，檢查點能成為下游應用程式標記事件「完成」的方法，也能針對在不同機器上執行的讀取器提供容錯移轉發生時的恢復功能。 縮短與此檢查點流程之間的位移可回到較舊的資料。 透過這項機制，檢查點可提供容錯移轉彈性，並支援事件串流重播。
重要
位移由事件中樞服務提供。 處理事件時，取用者必須負責檢查點查驗。
使用 Azure Blob 記憶體做為檢查點存放區時，請遵循這些建議：
- 針對每個取用者群組使用不同的容器。 您可以使用相同的記憶體帳戶，但每個群組各使用一個容器。
- 請勿將容器用於任何其他項目，也不會將儲存體帳戶用於任何其他項目。
- 儲存體帳戶必須與部署應用程式位於相同的區域中。 如果應用程式是內部部署，請嘗試選擇最接近的區域。
在 Azure 入口網站的 [儲存體帳戶] 頁面上，於 [Blob 服務] 區段中，確定已停用下列設定。
- 階層式命名空間
- Blob 虛刪除
- 版本控制
記錄壓縮
Azure 事件中樞支援壓縮事件記錄檔，以保留指定事件金鑰的最新事件。 使用壓縮的事件中樞/Kafka 主題，您可以使用金鑰型保留，而不是使用粗略的時間型保留。
如需記錄壓縮的詳細資訊，請參閱記錄壓縮。
常見的取用者工作
所有事件中樞取用者都會透過 AMQP 1.0 工作階段 (狀態感知的雙向通訊通道) 來連線。 每個資料分割都有 AMQP 1.0 工作階段，有助於傳輸資料分割所隔離的事件。
連接資料分割
連線至分割區時，通常是使用租用機制來協調讀取器至特定分割區的連線。 如此一來，取用者群組中的每個分割區就可能只有一個作用中讀取器。 使用事件中樞 SDK 內的用戶端作為智慧型取用者代理程式，可簡化檢查點查驗、租用和管理讀取器。 畫面如下：
- .NET 的 EventProcessorClient
- JAVA 的 EventProcessorClient
- Python 的 EventHubConsumerClient
- JavaScript/TypeScript 的 EventHubConsumerClient
讀取事件
在開啟特定資料分割的 AMQP 1.0 工作階段和連結後，事件中樞服務會將事件傳遞至 AMQP 1.0 用戶端。 相較於以提取為基礎的機制 (如 HTTP GET)，這個傳遞機制能產生更高的輸送量和較低的延遲。 將事件傳送到用戶端時，每個事件資料執行個體都包含如位移和序號等有助於在事件序列上設立檢查點的重要中繼資料。
事件資料︰
- 位移
- 序號
- 本文
- 使用者屬性
- 系統屬性
您必須負責管理位移。
應用程式群組
應用程式群組是用戶端應用程式的集合，可連線至事件中樞命名空間，共用唯一的識別條件，例如安全性內容 - 共用存取原則或 Microsoft Entra 應用程式識別碼。
Azure 事件中樞可讓您定義資源存取原則，例如指定應用程式群組的節流原則，以及控制用戶端應用程式與事件中樞之間的事件串流 (發佈或取用)。
如需詳細資訊，請參閱具有應用程式群組的用戶端應用程式的資源控管。
Apache Kafka 支援
Apache Kafka 用戶端的通訊協定支援 (版本 > = 1.0) 提供端點，讓現有的 Kafka 應用程式使用事件中樞。 大部分現有的 Kafka 應用程式都可以直接重新設定為指向命名空間，而不是 Kafka 叢集啟動程序伺服器。
從成本、營運工作量和可靠性的觀點來看，Azure 事件中樞是絕佳替代方案，可取代部署和操作您自己的 Kafka 和 Zookeeper 叢集，也可取代非 Azure 原生的「Kafka 即服務」供應項目。
除了享有與 Apache Kafka 訊息代理程式相同的核心功能，您還可以存取 Azure 事件中樞功能，例如透過事件中樞擷取來自動分批和封存、自動縮放和平衡、災害復原、成本中立的可用性區域支援、彈性又安全的網路整合，以及多重通訊協定支援，包括防火牆適用的 AMQP-over-WebSockets 通訊協定。
下一步
如需事件中樞的詳細資訊，請造訪下列連結：
- 開始使用事件中心