我有一個運行第三方服務器進程的Azure虛擬機。這個服務器進程通過調用一個我給它的可執行文件來通知我重要的事件，並將一些數據作爲命令行參數傳入。訪問Azure服務總線的可靠程度如何？
該數據需要被排隊，並通過另一個工人處理。
這是非常重要的是，這些通知都沒有錯過，所以我想知道：
是否可以接受（給我的要求），直接隊列中的消息，以在Azure服務總線？
或者我應該先排隊到本地MSMQ，然後有另一名工人從MSMQ讀取信息，並將其推入Azure的服務總線？
感謝
到服務總線的訪問是非常可靠的，但你總是要建立以應對「瞬時性故障」您的解決方案。通過這種方式，您可以檢查是否發生了某種故障（隊列上的臨時404，您身邊的連接問題等）。 這些故障稱爲瞬時故障，您應該重試。爲此，Service Bus客戶端具有內置功能，並且在客戶端上，您可以指定RetryPolicy。有不同的重試的政策可用，並且您可以創建自己的（ExponentialBackoff等） 檢查：http://msdn.microsoft.com/en-us/library/windowsazure/microsoft.servicebus.messaging.messagecliententity.retrypolicy.aspx
，如果你需要你的客戶端應用程序能夠脫機工作，那麼你可能需要建立一些自定義的存儲 - 轉發功能（您提到MSMQ，您也可以使用Windows Server的Service Bus）。唯一的缺點是目前沒有開箱即用的存儲轉發功能。
希望這有助於
我認爲MSMQ將是一條可行的路。這個過程是通過每個通知產生的，並且必須快速退出，以免有大量的問題出現。我認爲把它放在MSMQ中會比較安全，然後從那裏拿走它，而不是堅持要重試才能成功。非常感謝。 – Avram
這實際上取決於你的情況，但重試是非常特殊的（並且由SLA備份）。我總是希望保持架構和解決方案儘可能簡單，乍看之下，它看起來相當複雜，只是爲了可能存在連接問題的少數情況。 但是，這一切都取決於你的情況。 祝你好運 –
Azure的服務總線有99.9％的可用性（每年不超過8.76小時不可用）的保證。來源：http://www.windowsazure.com/en-us/support/legal/sla/
瞬態錯誤是Azure平臺是自然的一部分，因爲它需要在服務器之間移動部署。它們是由於Azure基礎設施「轉移」部署而導致的問題，可能會導致請求失敗。重新嘗試請求是解決問題所需的一切。
如何進行真正的問題是真的是你是否能夠承受數據丟失。在任何系統中，如果您需要某種保證數據不會丟失的方式，則需要編寫消息代碼，以便在將消息標記爲「已發送」之前確認將消息發送給接收方。
如果你在你的Azure隊列和你的應用程序之間放置了一個MSMQ服務，你仍然必須處理這個本地隊列可能不可用的可能性 - 如果你需要的話，知道這些消息不會丟失。必須確認接收情況並提供一種機制，以重新發送您未得到確認的消息。
「可靠」是一個相當模糊的術語。你需要知道什麼？ –
@Tragedian我想我想知道我是否可以假設服務總線的調用會成功。但因爲看起來我需要迎合短暫的缺點，所以我不能那樣做。 – Avram