【Azure 事件中心】EPH (EventProcessorHost) 消費端觀察到屢次Shutdown，LeaseLost的error信息，這是什麼狀況呢？

時間 2021-04-08

標籤算法編程 api 網絡負載均衡 ide 函數 spa 日誌欄目系統網絡简体版

原文原文鏈接

問題詳情

使用EPH獲取Event Hub數據時，屢次出現鏈接shutdown和LeaseLost的error ，截取某一次的error log如：算法

....

如何解釋EPH的Shutting Down呢？爲何出現LeaseLost(租約丟失)狀況呢？

問題解釋

在Azure SDK Microsoft.Azure.EventHubs.Processor 的解釋中列舉出LeaseLost是The lease was lost or transitioned to a new processor instance，表示當前租約丟失，或者轉移到一個新的Processor實例上。

這是由於Event Hub能夠設置多個分區，同時也能夠經過多個消費端來消費分區中的數據，可是多少個客戶端是最好的呢？根據【Azure 事件中心的 .NET 編程指南】中對EPH(Event Processor Host)的介紹，客戶端主機將嘗試使用「貪婪」算法獲取事件中心內每一個分區上的租約，若是當前只有一個消費端鏈接Event Hub，則當前消費端會把全部分區的租約都獲取過去。當有2個或者多個消費端時，它們會自動在多個消費端中進行負載均衡，最終達到動態平衡

只有一個消費端時（Azure Worker Role 1），8個分區都與它創建租約。
當有第二個消費端時（Azure Worker Role 2）, EPH就自動動態平衡分區數，最終表現爲各自處理4個分區數據。
而原來與Worker Role 1相連的5,6,7,8分區就會出現shutdown，緣由時leaselost的日誌記錄。

因此，咱們觀察到的Shutdown LeaseLost日誌消息就是由於EPH在自動進行多個實例間分區數的動態平衡而產生的。這是徹底正常的現象。

EPH出現LeaseLost的詳細分解

可見原文地址：https://stackoverflow.com/questions/41496754/what-is-causing-azure-event-hubs-receiverdisconnectedexception-leaselostexceptio/41867611#41867611

TLDR: This behavior is absolutely normal.

Why can't Lease Management be smooth & exception-free: To give more control on the situation to developer.

The really long story - all-the-way from Basics EventProcessorhost (hereby EPH - is very similar to what __consumer_offset topic does for Kafka Consumers - partition ownership & checkpoint store) is written by Microsoft Azure EventHubs team themselves - to translate all of the EventHubs partition receiver Gu into a simple onReceive(Events) callback.

... ...

譯文內容爲：

TLDR: This behavior is absolutely normal. 這是正常的行爲

爲何不能讓Event Hub分區租約的管理不出現異常呢？這是爲了更好地讓開發者來控制租約到期(Lease Lost)的狀況。

這須要從EventProcessorHost(簡稱 EPH)從建立之時提及， EPH是由Microsoft Azure EventHubs團隊開發，用來把全部的EventHubs partition receiver事件轉換爲一個簡單的回調事件 onReceive。這樣的目的是爲了解決在讀取高吞吐量分區數據流的狀況下的2個主要的，衆所周知的問題

1）容錯接收管道 (Fault tolerant receive pipe-line) - 若是運行PartitionReceiver的Host 宕機後恢復正常，則它須要從其宕機的地方繼續進行處理。爲了記住上一次成功處理的EventData，EPH使用提供給EPH構造函數的Blob來存儲檢查點(Checkpoints -調用context.CheckpointAsync（）時)。因此，當Host進程終止時（例如：忽然從新啓動或遇到硬件故障，再也沒法恢復），任何EPH實例均可以執行此任務並從該Checkpoint恢復。

2）在EPH實例之間動態分配分區 (Balance/distribute partitions across EPH instances) 假設有10個分區和2個EPH實例處理來自這10個分區的事件 - 須要一種在實例之間劃分分區的方法（PartitionManager組件）。使用Azure存儲-Blob LeaseManagement功能來實現這一點。從2.2.10版本開始 --- 簡化爲EPH假定全部分區均被加載。

基於以上的狀況，咱們來看一看EPH發生了什麼，首先，在上面的10個事件中心分區和2個EPH實例的示例中，處理其中的事件順序以下：

一：假設第一個EPH實例(EPH1)最初是單獨啓動的，它爲全部10個分區建立了接收器，而且開始處理事件。在啓動過程當中 --- EPH1將經過獲取表明這10個事件中心分區的租約（存儲Blob上）來宣佈擁有全部這10個分區（EPH在存儲賬戶中內部建立-從StorageConnectionString中獲取Blob)。可是該租約旨在指定時間內有效，有效期事後，EPH1會失去對分區的全部權

二：經過更新Blob上的租約，EPH1會連續續訂這10個分區的租約。續訂頻率以及其餘有用的調整可使用PartitionManagerOptions修改

三：啓動第二個EPH實例(EPH2), 而且使用與EPH1相同的StorageConnectionString。開始時，EPH2有0個分區要處理，爲了要在EPH實例之間實現分區的動態平衡，EPH2將下載租約列表（包含分區ID與擁有者的映射關係）。並會平均的截取5個分區的租約。在整個過程當中，EPH2會根據所獲取的分區信息獲得最新的檢查點（checkpoint），建立PartitionReceiver並繼續接收消息

四：最後，EPH1將失去對這5個分區的全部權，並將根據其分區的實時狀態而遇到不一樣的錯誤。

若是EPH1正在調用PartitionReceiver.Receive時，並且EPH2在同一分區建立PartitionReceive， EPH1就會碰見ReceiverDisconnectedException。而且調用EventProcessor.Close方法，Close Reason爲LeaseLost
若是EPH1處於checkpointing 或renewing 租約的狀態，而EPH2竊取了租約，則產生EventProcessorOptions.ExceptionReceived異常，eventHandler帶有leaselostException的信號（409 conflict error）-最終也會調用IEventProcess.Close （LeaseLost）

爲何不能讓Event Hub分區租約的管理不出現異常呢？（Why can't Lease Management be smooth & exception-free）

爲了使消費端簡單和無錯誤，EPH能夠吞下與租約相關的異常，而不經過用戶代碼的方式通知。可是，咱們意識到，拋出LeaseLostException可能使客戶可以在IEventProcessor.ProcessEvents（）回調中找到問題的根源 --- 多是頻繁進行分區移動形成

當消費端實例(EPH)發生輕微的網絡抖動，使得EPH沒法續訂租約而重啓。若是這個實例的網絡一直處於抖動狀況，EPH未來來回回獲取Partitions信息，同時不斷的嘗試從其餘EPH中竊取租約。這將致使消費端沒法處理正常的Event Hub事件。當發生這樣的狀況時，能夠在日誌中可見ReceiverDisconnectedException異常，這一點能夠很是好的幫助開發者定位問題。
或是在ProcessEvents的邏輯代碼中出現沒法處理的異常，並致使整個進程被破壞，分區也會在多個EPH實例之間來回移動。
也有多是在EPH中使用的儲存帳戶上有執行write/delete操做，與EPH實例執行的操做衝突等。
也有多是Azure的數據中心發生大範圍的宕機事件（不但願這樣的狀況發生），分區也會在多個EPH實例之間來回移動。

在大多數狀況下，對於Event Hub SDK而言，要檢測以上這些異常是很是棘手的。因此SDK團隊將控制權委託給開發者，開發者經過拋出的異常來定位問題。