檢測並刪除Azure服務總線上的孤立隊列，主題或訂閱

如果由於崩潰或其他異常終止（實例重新啓動等）而不再有任何發佈者或訂閱者讀取或寫入隊列，主題或訂閱。），是否Queue/Topic/Subscription有效地成爲孤兒？檢測並刪除Azure服務總線上的孤立隊列，主題或訂閱

我通過創建幾個隊列，然後終止應用程序來測試它。那些隊列很長一段時間還在服務總線上。看起來他們會永遠呆在那裏。如果我們想要這種行爲，那將是美好的，但在這種情況下，我們不這樣做。

我們如何檢測並刪除這些隊列，主題和訂閱？它們將計入Azure限制等，並且每次實例重新啓動/打補丁/崩潰時，我們都不會有這些孤立的進程。

如果它有助於使問題更清楚，這是一個獨特的情況，其中，隊列/主題/收藏有着特殊的名稱，或特殊的過濾器，以及一組非常有限的出版商（1）和用戶（1）在有限的時間內。這不是我們希望生存的情況。這些是特定於實例的響應渠道。無論我們使用隊列還是訂閱都不重要。如果實例消失，那麼需要該隊列（或訂閱）。

這是一個解決方案的一部分，每個Web角色都有一個專用的響應通道來監視。在任何時候，這個web角色可能會有數十個請求通過其他消息通道（隊列/主題）等待，並且正在等待多線程的答案。我們需要響應返回到放置消息的線程，以便Web角色可以響應調用者。在這種情況下，僅憑基於機器的訂閱是不好的，因爲它將接收其他線程的消息。我們需要每個發佈線程來建立一個專用的響應通道，這樣該通道上唯一的事情就是該線程的響應。

即使我們使用訂閱（通過某種與實例相關的過濾器）在訂閱上進行長輪詢接收操作，但如果Web角色實例死亡，該訂閱將成爲孤兒，是否正確？

這個問題可以這樣歸納如下：如果沒有更多的發佈者或訂閱者進入隊列/主題/訂閱，那麼該服務將被有效地孤立。這些孤兒如何被發現並清理？

來源

2012-09-08 Pittsburgh DBA

我們可以說明您正在討論Azure中的隊列（SB中的雲）或Windows Server隊列服務總線（Service Bus 1.0 Beta）嗎？ – user728584

這是關於Azure的。 –

在這種情況下，你正在尋找排隊/訂閱本質上是「動態」。根據使用情況創建和刪除它們，而不是針對這些實體的當前顯式配置模型。 Service Bus爲您提供了執行創建/刪除操作的API，以便您可以將這些操作適當地插入角色OnStart/OnStop事件。如果這些操作由於某種原因失敗，那麼孤兒實體將存在。再次，您可以基於實體名稱的某個唯一標識符對它們執行清理操作。例如：http://windowsazurecat.com/2011/08/how-to-simplify-scale-inter-role-communication-using-windows-azure-service-bus/

在不久的將來，我們將向隊列/主題/訂閱添加更多元數據和查詢功能，以便您可以查看他們上次訪問的時間並作出清理決定。

來源

2012-09-11 21:55:07

服務總線隊列使用旨在集成跨多種通信協議，數據合同，信任域和/或網絡環境的應用程序或應用程序組件的「代理消息」基礎架構構建。允許機制與持久消息傳遞可靠地進行通信。

如果客戶端（發佈者）向服務總線隊列發送消息，然後崩潰，消息將存儲在隊列中，直到消費者從隊列中讀取消息。此外，如果您的客戶死亡並重新啓動，它只會輪詢隊列並接收任何正在等待的工作（您可以擴展並讓多個客戶從隊列中讀取以增加吞吐量），Service Bus Queues允許您通過耐用的雲網關類似於MSMQ內部部署（或其他排隊技術）。

我真的想說的是，你不會得到一個孤兒隊列，你可能會得到你需要處理的中毒消息，這篇博客文章提供了一些非常詳細的信息：服務總線隊列及其容量和配額可能給你一個更好的瞭解http://msdn.microsoft.com/en-us/library/windowsazure/hh767287.aspx

回覆：隊列管理器，您可以通過Visual Studio的（1.7 SDK &工具），或做到這一點有一個叫做服務總線瀏覽器很好的工具，將讓您的生活更輕鬆隊列管理：http://code.msdn.microsoft.com/windowsazure/Service-Bus-Explorer-f2abca5a

*請注意，默認的最大隊列數是10,000（每個服務名稱空間，這可以通過支持電話增加）

來源

2012-09-09 01:00:34 user728584

謝謝你的回覆。我的問題不是關於隊列的耐久性。我會重新說說它。 –

如果您的進程將崩潰，這是非常可能的將有消息在隊列中傳遞的問題，但隊列仍然可用於處理您的請求。使用Windows Azure服務總線隊列處理應用程序崩潰和無法讀取的消息描述here：

服務總線提供的功能可以幫助您正常地從應用程序中的錯誤中恢復或處理消息時遇到困難。如果接收方應用程序由於某種原因無法處理消息，則可以在接收到的消息（而不是Complete方法）上調用Abandon方法。這將導致服務總線解鎖隊列中的消息，並使其可以再次接收，無論是由同一消費應用程序還是由另一個消費應用程序接收。

如果應用程序在處理完消息後但在完成請求發出之前崩潰，則消息將在重新啓動時重新發送給應用程序。這通常稱爲「至少一次處理」，即每個消息至少要處理一次，但在某些情況下，可能會重新傳送相同的消息。如果場景不能容忍重複的處理，那麼應用程序開發人員應該爲其應用程序添加額外的邏輯來處理重複的消息傳遞。這通常是使用消息的MessageId屬性實現的，消息的MessageId屬性在傳遞嘗試期間保持不變。

來源

2012-09-09 01:13:18 AvkashChauhan

謝謝你的回覆。這些信息很有用，但我想我可能對我的問題措辭不佳。我會提出更好的問題。 –

如果由於崩潰或其他異常終止（實例重啓等）而不再有任何進程正在讀取或寫入隊列，那麼該隊列是否會被有效孤立？

沒有隊列到位，允許通過經紀公司的消息發生通信，如果所有的應用程序死因爲某些原因則隊列仍然存在，並且將在那裏當他們再次變得活躍，它是鬆散的溝通渠道解耦應用程序。問候結算'根據服務總線在帳單月份內發送或發送的郵件數量收取費用'如果隊列存在但無人使用，您將不會收費。

我通過創建幾個隊列，然後終止應用程序來測試它。稍後，這些隊列仍然在機器上很長時間。

隊列的整點是保證鬆散解耦應用程序的消息傳遞。將隊列視爲一個實體或應用程序，並將它作爲其在Azure中託管的高可用性（SLA），您的生產者/消費者可以死亡/重新啓動，隊列將在Azure中處於活動狀態。 *注意我對你的措辭感到困惑：「很長一段時間後仍然在機器上」，隊列實際上並不在你的機器上，它位於指定的服務總線命名空間的Azure中。您可以通過我在前面的答案中指出的工具查看和管理隊列。

我們如何檢測和刪除這些隊列，因爲他們將走向 Azure的空間限制等

如上隊列的默認最大數量規定爲10,000（每個服務命名空間，這樣可以通過支持呼叫增加），隊列管理可以通過其他答案中陳述的工具完成。當您不再有製片人/消費者希望寫信給他們（即不再是）時，您應該只希望刪除隊列。當然，你可以創建並通過namespaceManager.QueueExists您的生產者/消費者應用程序刪除隊列，這裏更多信息How to Use Service Bus Queues

如果它有助於使問題更清楚，這是一個獨特的情況，其中隊列具有特殊名稱，以及在有限時間內非常有限的一組出版商（1）和訂閱者（1）。

這聽起來像你需要使用的主題&訂閱How to Use Service Bus Topics/Subscriptions，這個環節也有「如何刪除主題和訂閱」如果你有一個非常有限的壽命，那麼你可以在處理主題創建/刪除的部分您應用程序的，否則你可能有一個單獨的隊列/主題/訂閱設置/刪除腳本來處理這種邏輯...

來源

2012-09-09 20:14:13 user728584

沒有人接觸到我在這裏問的問題。當我說「還在機器上」時，我的意思是這些隊列在雲中仍然存在，這是非常不容易的。這個問題的關鍵在於我們有一個非常具體的專有情況，我們希望每個Web角色都有專門的隊列。 Web角色將是訂閱者，並且在運行時，它會告知各種工作進程使用該通道作爲響應隊列。如果該Web實例崩潰或由Fabric控制器重新啓動，或者其他任何情況，該隊列將被孤立。我們如何清理它？ –

隊列將被孤立的原因是因爲它是web角色實例特定的，並且如果web角色實例死亡或重新啓動，將不會有更多的發佈者或訂閱者用於此隊列。然而，根據我的直接觀察，這導致隊列在服務總線上保持活動。我知道我不會被指控，而且我的問題也沒有提到任何有關指控。我的問題提到了限制。如果我們使用主題/訂閱，則會發生同樣的問題。如果用戶（網絡角色）死亡，訂閱將被孤立，因爲它將是特定於實例的。 –

正如Abhishek Lai提到的那樣，沒有支持孤兒檢測功能。

孤兒檢測可以通過多種方式在外部實現。例如，無論何時發送/接收消息，都要更新SQL數據庫中的時間戳，以指示隊列/熱帶/訂閱仍處於活動狀態。這個時間戳然後可以用來確定孤兒。

來源

2012-09-11 22:26:41 hocho

檢測並刪除Azure服務總線上的孤立隊列，主題或訂閱

回答

相關問題