Azure Service Bus訂戶定期打電話回家？

Question

我們有pub / sub應用程序，涉及通過Azure Service Bus主題訂閱Web角色發布者的外部客戶端。 我們當前的結算周期表示我們已發送/接收> 25K消息，而我們的信息中心表示我們已發送<100。 我們正在調查我們的實施並檢查我們的假設，以便了解這種差異。

作為調查的一部分，我們在客戶端計算機上收集了客戶端<=>服務總線流量的wireshark捕獲。 我們注意到了一種我們尚未見過的常規溝通模式，並且希望更好地理解。 如果總線上沒有任何活動，則每50秒進行一次以下交換：

1. 客戶端將~200B推送到服務總線。
2. 10s后，服務總線將~800B推送到客戶端。 客戶端注冊空消息的接收（通過斷點確定）。
3. 客戶端立即響應〜1000B到服務總線。

一些相關信息：

• 當我們的Web角色沒有主動將數據推送到服務總線時，就會發生這種情況。
• 在從Web角色接收到合法消息后，上述模式將不會再發生，直到整整50秒過去。
• 客戶端和服務器都通過TCP連接到sb：// namespace .servicebus.windows.net。
• 我們的應用程序消息<64 KB

問題

1. 我們看到的常規3分組消息交換負責什么？ 它是某種保持活力嗎？
2. 3個數據包中的每一個都被視為單獨的可計費消息嗎？
3. 此行為是可配置還是以其他方式記錄？

編輯：

這是接收消息的代碼：

    private void Listen()
    {
        _subscriptionClient.ReceiveAsync().ContinueWith(MessageReceived);
    }

    private void MessageReceived(Task<BrokeredMessage> task)
    {
        if (task.Status != TaskStatus.Faulted && task.Result != null)
        {
            task.Result.CompleteAsync();
            // Do some things...
        }
        Listen();
    }

Answer 1

我認為你所看到的是后台的接聽電話。 在幕后，接收呼叫都使用長輪詢。 這意味着他們呼叫服務總線端點並要求提供消息。 Service Bus服務獲取該請求，如果有消息，它將立即返回。 如果它沒有消息，它將保持連接打開一段時間以防消息到達。 如果消息在該時間范圍內到達，則將其返回給客戶端。 如果在時間幀結束時消息不可用，則會向客戶端發送響應，指示沒有消息存在（也就是您的null BrokeredMessage）。 如果您在沒有重載的情況下調用Receive（就像您在此處所做的那樣），它將立即發出另一個請求。 此循環繼續發生，直到收到消息。

因此，您看到的是客戶端請求消息但在那里沒有消息的次數。 長輪詢使其比Windows Azure存儲隊列更好，因為如果沒有消息，它們將立即返回null結果。 對於這兩種技術，通常會對請求實施指數退避。 有很多關於如何做到這一點的例子。 這會減少您檢查隊列的頻率，並可以減少您的交易次數。

回答你的問題：

1. 是的，這是正常的預期行為。

2. 不，這只是一筆交易。 對於Service Bus，每次將消息放入隊列並且每次請求消息時都會收取一筆交易（鑒於Recieve在后台多次撥打電話，這可能會有點不透明）。 請注意，文檔指出您為每個空閑事務收取費用（意味着來自Receive調用的null結果）。

3. 同樣，您可以實現退避方法，以便您不會經常訪問隊列。 我最近聽到的另一個建議是，如果你有一個沒有看到大量流量的隊列，你也可以在進入循環進行處理之前檢查隊列深度，看它是否> 0，如果你沒有收到任何消息接聽電話你可以回去看隊列深度。 我沒有嘗試過，如果你經常進行隊列深度檢查，你可能會受到限制。

如果這些是您的生產數字，那么您的訂閱並不真正處理大量消息。 在處理之前等待可以接受的時間可能是一個非常好的主意。 比如，如果一條消息可以存在超過10分鍾，那么創建一個退出方法，最終每10分鍾檢查一條消息，然后當它獲得一個進程並立即再次檢查時。

哦，有一個接收超載，需要超時，但我不是100％，這是服務器超時或本地超時。 如果它是本地的，那么它仍然可以每隔X秒向服務進行一次調用。 我認為這是基於在創建SubscriptionClient時在Messaging Factory設置上設置的OperationTimeout值。 你必須測試一下。