簡體   English   中英

一個隊列上的多個 Azure Webjob 實例(第 2 部分)

[英]Multiple Azure Webjob instances on one queue (part2)

我正在尋找一些關於如何設置處理單個隊列的 Azure webjob 的多個實例的文檔。 我看到了這篇文章: 一個隊列上的多個 Azure Webjob 實例,這很有幫助。 我最大的收獲是,如果我將應用服務擴展到多個實例,“每個作業實例將從隊列中選擇不同的消息”。 太好了,它確保我的工作不會重復。

但是,我想知道如果我創建一個重復的、單獨的應用程序服務(每個服務具有相同的 Web 作業)並同時運行這兩個(或更多)實例而不是簡單地“擴展”,是否也是如此。 這樣做的原因很簡單,因為我需要更多的出站 IP 地址。 我的網絡作業使用的第三方 api 通過 IP 地址限制我。 因此,隨着我的應用程序獲得更多用戶,並且我“向外擴展”,我開始從這個第三方 API 獲得越來越多的超時。 我提出的解決方案是創建獨立的應用程序服務,這些服務本質上是克隆的。 但我想確保來自隊列的作業不會被復制。

作為參考,以下是我的網絡作業功能的樣子:

public void ProcessQueueMessageAsync([QueueTrigger("quicktransferqueue")] string message, ILogger logger)
{
    var model = Newtonsoft.Json.JsonConvert.DeserializeObject<QuickTransferModel>(message);
    //Hit my third-party API here...
}

使用 QueueTrigger 的 WebJobs(和 Azure Functions)將為您處理隊列消息的可見性,並在處理消息時立即隱藏消息。 這有效地將它鎖定在給定時間間隔內的其他工作人員中(如果您的功能失敗,它不會立即將其從隊列中刪除)。 成功完成函數調用后,它將被刪除。 QueueTrigger 是來自單個函數的多個實例,還是來自訪問同一隊列的多個不同函數,這並不重要。 因為它們立即“隱藏”了它們拉出的消息,所以另一個嘗試輪詢隊列的進程將看不到那些正在被積極處理的消息。 隊列本身不知道有多少不同的作業/功能試圖訪問它——它只是管理消息及其可見性。 簡而言之,你很安全。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM