任何人都可以回答我 - 短信/電子郵件門服務如何工作？asp.net高負載短信/電子郵件調度程序架構
一般來說，我需要asp.net mvc 3 web應用程序，它應該支持高負載短信/電子郵件API（例如，100 - 500每秒API請求）。在這種情況下應該使用什麼架構/算法？我認爲是錯誤的，解決方案（糾正我，如果它很糟糕）： 1）許多Http（或肥皂等）請求我的服務。像「www.example.com/sms-api/send?blabla」一樣。 2）插入db中的每個請求 3）Win服務迭代db中的所有行，其中status = NotInProcess（示例）。 4）繼續處理新線程中的每個項目（是否正常/正確？）並執行它（發送電子郵件，例如，來自其他服務的記錄/等待答案等）。
我知道，對我的問題應該存在任何「最佳實踐」，但我沒有找到它......任何人都可以幫助我解決我的架構問題嗎？
這取決於解決方案的要求。
性能： 如果排除持久性，你可以節省大量的性能點。因爲寫入數據庫非常昂貴。從DB讀取也很昂貴。
可擴展性： 調度所有傳入消息傳送到其他（多個）主機。一開始，您可以將這些主機放在同一臺服務器（網絡）上，因爲負載會增加您在您身邊添加更多服務器和主機，或者使用付費雲服務和並行發送消息。您也可以將消息發送到持久性和其他必需的主機（我相信您需要身份驗證，授權，計費等）。）
可用性： 如果一些主機停機？您需要恢復傳入數據並在主機處於活動狀態後繼續分派。
可維護性： 你應該能夠很容易地刪除/替換/添加新主機，加工，高/低負載等
假設這一切我覺得很適合架構，你的問題是SOA （面向服務的體系結構）。它可以基於MSMQ或RabbitMQ作爲傳輸和NServiceBus作爲框架。在這裏閱讀更多：http://particular.net/nservicebus
它可能比這更復雜一點，特別是處理故障和滿足您的全部要求。我認爲一旦你定義了這個，架構可能會更清晰。您充當短信/電子郵件網關。這意味着無論您通過何種方式發送這些消息都可能導致其自身的失敗這對您的應用程序意味着什麼？你自己會失敗嗎？你想繼續重試發送嗎？
如果您的外部服務失敗，並且失敗，那麼使用WCF（或ASP.NET MVC 4和WebAPI）執行正常的REST API可能就足夠了。
如果您想不斷重試代表您的客戶端發送消息，那麼您可能需要查看諸如Microsoft Azure Queues以及WCF中的REST API（如上所述）。當客戶端連接時，您將添加要發送到Azure隊列的消息，並使用線程（或輔助角色）監視新添加項。使用隊列有什麼好處，你可以在消息來臨時處理消息，而且它很耐用。這意味着如果您的服務在嘗試發送消息時發生故障，您不會丟失隊列中的任何數據。它給了你更多的容錯能力（假設你正確實現了它）。
你可能還想看的一件事是Quartz.NET。這將讓您安排線程在特定的時間表上重複執行。這可能對縮放重試機制有用。如果您的外部服務失敗，請在1分鐘後重試。如果再次失敗，請在15分鐘後重試（等）。