如何使用SQL Server和Windows Azure通知集線器發送預定時間通知？

Question

讓我來解釋一下我們已經做了什麼，然後嘗試實現的當前情景。

現有架構：在我們當前的架構中，我們有一堆服務和一個SQL Server數據庫。這些服務允許移動設備（Android/IOS）允許用戶註冊/登錄，然後設置他的日程安排，比如說「我需要在中午12點吃午飯」。

Android應用程序在當天結束時爲第二天的設備輪詢所有時間表，然後在第二天的適當時間顯示這些時間表。

的問題這種方法的缺點是，第一，可能（已報告給我）IOS不能做這樣的事情保持在後臺的時間表，然後當時間出現在顯示和第二，這ISN」處理這種情況的最佳方式 - 如果用戶在「移動應用完成其調度後」更改了「時間表」。

---

所以，我想出了一個架構來解決這個問題（提出的架構1），並在進一步的調查也認爲處理這種不同的方式（提出的架構2），並提的是，太在這裏下面。你能幫我解決我的查詢，並試圖瞭解什麼會最好的工作：

建議Arch。 1：請看下圖 -

這個架構非常簡單。我們在此建議，我們可以使用SQL依賴關係+查詢通知來了解計劃表（其中包含所有計劃以及何時用戶添加，更新或刪除計劃，將引發查詢通知）中的更改。這個SQL Server分開存在並且不在雲上。

我們Azure的移動服務將有處理此查詢通知，一旦它得到一個通知，它會以更新的時間表更新自己的Azure的SQL數據庫，然後它會「提示」其自己的調度程序自定義下一次重新調用 - 即 - 調度程序將檢查Azure SQL DB中的日程表，並且如果有通知要發送，則使用通知中心發送通知，然後重新調度自己爲下一次當它發送通知時

現在最大的任務使用這種方法是 - 我們非常肯定，我們可能有數百甚至數千用戶同時更新他們的時間表 - 當發生這種情況時，我不是用戶該架構如何表現 - 它會中斷嗎？ - 另外，如果調度程序運行並發現它必須發送1000個特定時間的通知，比如說下午6點，它是否會在不中斷的情況下發送通知中的等待時間 - 例如通知本來應該在下午6:00發送大約下午6:05

---

是越來越發送一邊想着這個問題，我們想出了這個未來提出的架構：

建議拱門。 2：

在這個架構下，我們認爲爲什麼不把調度的東西轉移到SQL服務器上，並創建一個每分鐘運行的作業（因爲沒有人會在一分鐘內設置一個時間表 - 即 - 一個人將在下午6:35設置時間表，而不是在6:35:09 pm）

此外，此過程僅涉及SQL CLR對象和通知中心，並且不包含Azure移動服務或Azure SQL數據庫。

因此，該過程將是這樣的：

• 一個SQL Server作業將被安排運行每隔一分鐘
• 說，如果這項工作開始於下午5:00它的外觀是否有是下午5點1分的任何預定通知 - 如果是，則開始發送其通知
• 如果不是，則默默結束，然後在下午5:01重新調用以查看是否有任何時間表5:02 pm
• 繼續以相同的方式直到明確停止

主要關心的是，這將工作？

對於每一分鐘安排一項工作（即使SQL Server具有該選項）是否是一種很好的做法？

如果在下午5點01分發現它有1萬個通知要在5:02 pm發送，該怎麼辦？它將能夠發送所有的這些

順便說一句，在這個架構中發送，我們會使用Azure的通知中心的通知，並會有一個SQL CLR函數說，「發送通知」，將勾此通知中心，並在預定作業調用時發送通知。

請給我建議其他鏈接，指出更好的處理方式。我的客戶非常關心我們如何處理通知的方式，如果我們一次不得不發送太多的郵件，我們會盡快給您回覆。

非常感謝所有回答/評論者！ :)

Answer 1

您是否探索過可能使用通知中心的SendScheduledNotifications API。你可以在這裏閱讀更多關於它的信息：https://msdn.microsoft.com/en-us/library/azure/dn790626.aspx。