我對此的知識和經驗有限，所以不確定我是否考慮了所有內容並希望得到一些建議。ASP.NET SMTP故障轉移解決方案
當前場景：一臺Exchange服務器，一臺數據庫服務器，多臺負載平衡的Web服務器，所有服務器都定期發送確認郵件和警報郵件。這個交換服務器在整個業務中廣泛使用，導致交換服務器無法處理的高負載。有一段時間，服務器延長了一段時間，導致電子郵件未到達目的地，並且沒有記錄電子郵件嘗試確定哪些電子郵件失敗，因此可以在以後手動發送。此外，網站等待SMTP響應，因此網頁加載時間延遲。
計劃：將引入第二臺SMTP服務器，以減少原始服務器上的負載，同時對網站實施一些改進以減少資源浪費並改進所有電子郵件嘗試的日誌記錄（只是標題信息）， SMTP響應狀態。
可能的解決方案：
更改網站的電子郵件方式登錄，然後通過一個或其他服務器嘗試SMTP，記錄SMTP響應。優點：開發速度更快，缺點：沒有電子郵件隊列的異步處理。
記錄電子郵件標題，然後使用MSMQ或RabbitMQ發送電子郵件請求到一個隊列，並有一個偵聽器服務處理實際發送電子郵件到Exchange服務器的過程。此外，如果它仍然無法訪問SMTP服務器，請將其保留在隊列中，稍後重試。優點：可以重用基礎設施和體驗，以便在將來的功能要求中使用MQ，例如用戶請求下載數據的Facebook。缺點：有時間學習如何去做，並在面臨最後期限時實際發展。
將電子郵件記錄到數據庫，然後發送到中繼到Exchange服務器的本地提取文件夾，但我認爲這沒有故障轉移支持或用於更新電子郵件日誌中狀態的方法，所以雖然看起來很快根據我的觀察，它並沒有真正滿足所有的要求。
什麼我很想做的是做的是分兩個階段發展，最初只是第一個解決方案可以開發MSMQ/RabbitMQ的功能，使之異步在稍後的日期，但想到我會問意見，看看我是否忽略了一些事情。
是否有一個要求，爲您選擇使用Exchange ** **所有電子郵件？如果沒有，您可以/應該查看有能力爲您的消息傳遞需求排隊並進行故障轉移的外部服務。我可以想象，如果服務器執行「所有事情」（垃圾郵件/反X等），您的服務器就會受到負載。如果可能的話，考慮外包你可以...... – EdSF
這將是一個很好的解決方案通常，但不幸的是這是一個客戶端，他們通過自己的服務器，而不是外包他們的電子郵件。 –
如何確定哪些電子郵件只能使用IIS SMTP服務器與Exchange - 例如網站電子郵件，交易電子郵件等 - 您的每個Web服務器都可能位於SMTP服務器池中。我仍然想弄清楚哪些**必須**使用Exchange與其他MTA ...... – EdSF