Azure Service Bus主題訂閱者收到訂單

Question

我正在使用azure服務總線主題作為解決方案的消息代理。 據我了解，對於每個訂閱，Azure消息總線都會保留一個虛擬隊列 ，因此在接收消息的結束順序時不應受到干擾。

但實際上有點不同，在我的情況下

• 輸入大約每隔兩秒鍾一次，（時間戳是正確的，我已經驗證了）
• 如果我斷開接收器的連接一段時間，則消息開始在Azure上針對訂閱排隊。
• 然后，如果我再次連接接收者，接收代碼會很快接收到消息，但是順序是否保持不變？
• 但是，如果我保持客戶端連接狀態，則會按順序接收消息（兩秒鍾后有1條消息）

接收碼

SubscriptionClient Client = SubscriptionClient.CreateFromConnectionString(connectionString, topicname, subscription_name);

                // Configure the callback options.
                OnMessageOptions options = new OnMessageOptions();
                options.AutoComplete = false;
                options.AutoRenewTimeout = TimeSpan.FromMinutes(1);

                // Callback to handle received messages.
                Client.OnMessage((message) =>
                {
                    try
                    {
                        // Process message from queue.
                        string payload = message.GetBody<string>();
                        var myData = JsonConvert.DeserializeObject<MyData>(payload);
                        if(myData != null)
                        {

                            //Timestamp is not in order, when I connect after few minutes
                            Debug.WriteLine("SBC ==> " + myData.Timestamp);

                        }
                        // Remove message from queue.
                        message.Complete();
                    }
                    catch (Exception)
                    {
                        // Indicates a problem, unlock message in queue.
                        message.Abandon();
                    }
                }, options);

輸出量

SBC ==> 5/23/2017 1:06:43 PM
SBC ==> 5/23/2017 1:06:45 PM
SBC ==> 5/23/2017 1:07:23 PM
SBC ==> 5/23/2017 1:07:19 PM
SBC ==> 5/23/2017 1:07:27 PM
SBC ==> 5/23/2017 1:07:07 PM
SBC ==> 5/23/2017 1:06:49 PM
SBC ==> 5/23/2017 1:07:47 PM
SBC ==> 5/23/2017 1:06:47 PM
SBC ==> 5/23/2017 1:08:03 PM
SBC ==> 5/23/2017 1:06:55 PM
SBC ==> 5/23/2017 1:06:51 PM
SBC ==> 5/23/2017 1:07:03 PM
SBC ==> 5/23/2017 1:07:51 PM
SBC ==> 5/23/2017 1:06:57 PM
SBC ==> 5/23/2017 1:07:05 PM
SBC ==> 5/23/2017 1:07:39 PM
SBC ==> 5/23/2017 1:07:43 PM
SBC ==> 5/23/2017 1:06:59 PM
SBC ==> 5/23/2017 1:07:09 PM
SBC ==> 5/23/2017 1:06:53 PM
SBC ==> 5/23/2017 1:07:33 PM
SBC ==> 5/23/2017 1:07:25 PM
SBC ==> 5/23/2017 1:07:57 PM
SBC ==> 5/23/2017 1:08:13 PM

有人可以解釋為什么嗎？ 這讓我有點困惑？

Answer 1

雖然天藍色服務總線將其自身作為FIFO（先進先出）提供，但實際上僅在不中斷的會話期間有效。 如您所經歷的：

但是，如果我保持客戶端連接狀態，則會按順序接收消息

要解決此問題，您可以使用其他模式。 在下面的鏈接中查看ReceiveAndDelete和PeekLock模式。

服務總線文檔

這是一些相關的堆棧溢出文章，可能會對您有所幫助。

如何使用Azure服務總線主題完成FIFO

如何保證天藍色隊列FIFO

編輯

此鏈接包含有關FIFO的一些詳細信息

以下是該文檔的引文，該引文指定您需要使用消息傳遞會話才能獲得FIFO。

服務總線隊列中有保證的FIFO模式需要使用消息傳遞會話。 如果應用程序在處理以“偷窺和鎖定”方式接收的消息時崩潰，則隊列接收者下一次接受消息傳遞會話時，將在其生存時間（TTL）期限到期后從失敗的消息開始。

在實現消息會話方面，文檔似乎相當缺乏，但據我了解，它來自MessageSession類，它是AcceptMessageSession方法。

Answer 2

就像@NPhillips所說的那樣，您需要使用ASB的Message Sessions功能來實現FIFO行為。 這意味着幾件事，需要注意：

1. 接收者一次只會處理一個會話
2. 並發處理是不可能的，無論處理什么時間，您都會收到一條消息。
3. 發件人需要為每個消息分配會話ID。

最好的樣本和解釋將是一個張貼由ASB團隊在GitHub上這里 。