MSMQ緩衝用於SQL Server插入

Question

我瞭解MSMQ和我成功地用它來從面向消費者的ASP.NET MVC網站排隊的電子郵件和短信，由一個獨立的客戶端應用程序來處理。

如果缺少SQL Server數據庫，可能在交換驅動器或損壞的數據庫部署時，將非時間關鍵型插入排入本地MSMQ隊列以提高正常運行時間是否合理？

理論上，然後我可以暫停/恢復隊列處理（持久性），同時使數據庫的變化。有沒有人試過這個或有更好的方法？

Answer 1

我是在一個團隊中實現此擔保交付的目的。我們使用MSMQ將插入請求轉發給數據庫服務器，數據庫服務器有自己的服務運行，使請求出隊並運行插入，然後確認消息（以確保傳送）。它已經運行了一年多了，我們從來沒有被要求弄清楚它爲什麼不能正常工作......對我來說似乎相當穩固。

Answer 2

這是非常主觀的，因爲它取決於你的應用程序做什麼和如何。一般來說，像MSMQ這樣的東西不是用於這個目的的，而是你想在你選擇的數據庫上設置某種高可用性集羣。數據庫完全停止運行的情況在大多數情況下很少出現，而且對於大多數LOB應用程序來說，這通常是一個更大的問題，因爲無論出於何種原因，只需要在某處存儲輸入數據時輸入數據即可。

還有值得考慮的開銷。對數據庫的INSERT操作相對較快（在更大的方案中）;寫連載東西到隊列中，並具有東西它撿起來，做的插入操作將大量的滯後添加到您的應用程序，更何況事實，你必須考慮到一個事實，即現在一切都是異步的。

也就是說，MSMQ 可以用於確保從應用程序的一端到另一端的東西的交付，所以我想有些情況下可能需要這種情況。大多數情況下，儘管信任數據庫並使用MSMQ來啓用異步處理並執行進程間和機器間通信會更好。

Answer 3

如果你通過本地排隊，那麼你應該考慮Service Broker部署在與你的IIS/ASP實例並置SQL Express實例看着更高的可用性。使用SSB優於MSMQ的優點是，您的消息存儲和數據存儲之間具有一致性（一個一致的備份/恢復，一個一致的故障轉移單元），它在負載情況下比MSMQ的擴展性要好得多，不需要雙相 - 提供DTC來協調MSMQ出隊與數據庫插入（可以使用一個本地數據庫事務進行出列/插入），它提供待處理消息的可查詢性（SELECT .. FROM queue），與數據庫HA/DR解決方案（集羣故障轉移/鏡像），你會得到包含activation的數據庫，並且這些數據都來自熟悉的T-SQL編程環境。 MSMQ的主要優勢是支持客戶端C＃/ .Net API。