2016-12-09 83 views
0

This page描述瞭如何使用Azure Service Bus中的會話將來自同一源的消息分組到相同的接收方中。Azure服務總線會話 - MaxConcurrentSessions與MaxConcurrentCalls

在會話少隊列處理器,我可以控制,我可以有多少條消息在並行獲得:

new OnMessageOptions { MaxConcurrentCalls = 10 }; 

如果我通過這些選項,不超過10條消息將在同一時間進行處理。現在

,用於會話FUL處理器的選項是由

new SessionHandlerOptions { MaxConcurrentSessions = 10 }; 

其中有不超過10 會議在同一時間的不同的含義所取代。

我的會話是相對長壽的,而且大部分空閒,所以我必須將此參數設置爲較高值。但是,我仍然想限制並行消息的數量。

開箱即可使用嗎?

如果我將MaxConcurrentSessions設置爲int.MaxValue,那麼實際的並行化限制是多少?

回答

0

從文檔:

單一接收器進程可以輕鬆地處理很多併發會話,尤其是當它們與嚴格異步代碼編寫;與回調模型有效地自動處理數十個併發會話。

在當你有很長壽命多個會話情況:

處理很多併發會話,其中每個會話只零星地接收消息的策略是處理程序後,刪除會議一些空閒時間,並在下一個會話到達時接受會話時再次選取處理。

+0

不過,我不知道如何選擇'MaxConcurrentSessions'。比如說,我的空閒超時時間是1分鐘,每條消息需要1秒的時間來處理,我想處理最多10條併發消息。然後,我必須將MaxConcurrentSessions設置爲60 * 10。但這可能意味着SB會同時接受600場新的會議? – Mikhail

+0

將MaxConcurrentSessions設置爲600確實最多可以處理600個會話。這一切都取決於這些消息到達的會話。我認爲你想要做的就是保持你的'MaxConcurrentSessions'爲10,並且一旦你處理了一個會話的消息,就放棄這個會話(按照文檔規定)。有很多我不知道你的系統,所以不能回答我不知道的。爲什麼10個併發消息,而不是更多,這是其中之一。此外,測試一下,看看你對工作/閒置時間的假設是否有效,或者導致某些會議「餓死」。 –

+0

需要限制以避免從隊列處理器調用的外部系統過載。我現在試圖在每個處理後的消息後關閉會話。似乎工作ok-ish,但我想這導致同一會話的所有預取消息被返回到隊列並被標記爲不成功,直到下一次重試。我想我必須做「超時」的事情,但是我回到了限制會話計數與消息計數的問題。 – Mikhail