【发布时间】：2016-02-24 05:38:29
【问题描述】：
让我解释一下我们已经做的当前场景以及我们正在努力实现的目标。
现有架构：在我们当前的架构中，我们有一堆服务和一个 SQL Server 数据库。该服务允许移动设备（Android/IOS）允许用户注册/登录，然后设置他的日程安排，例如“我需要在中午 12:00 吃午饭”。
Android 应用会在当天结束时轮询设备在第二天的所有日程安排，然后在第二天的适当时间显示这些日程安排。
这种方法的问题是，首先，可能（据我报告）IOS 不能做一些事情，比如将日程安排在后台，然后显示时间发生并且第二，这不是处理此问题的最佳方法 - 如果用户在移动应用程序完成其计划之后更改计划怎么办。
所以，我想出了一个解决这个问题的架构（Proposed Architecture 1），在进一步的调查中，我还想到了一种不同的方法来解决这个问题（Proposed Architecture 2 >) 并在下面提到这一点。您能帮我解决我的相同问题并尝试了解最有效的方法吗：
这种架构非常简单。我们在这里建议我们可以使用SQL Dependency + Query notification 来了解Schedule 表中的变化（该表包含所有的日程表，当任何用户添加、更新或删除日程表时，查询通知将被抛出）。此 SQL Server 单独驻留在云上。
我们的 Azure 移动服务 将有一个此查询通知的处理程序，一旦收到通知，它就会使用更新的时间表更新自己的 Azure SQL DB然后它会“提示”它自己的调度程序以自己为目标以进行下一次重新调用 - 也就是说 - 调度程序将检查 Azure SQL DB 中的调度，如果有通知要发送，它将，然后使用通知中心发送通知，然后在下次必须发送通知时重新安排自己
现在这种方法的最大问题是 - 我们很确定我们可能有成百上千的用户同时更新他们的日程安排 - 当这种情况发生时，我不是用户如何使用这种架构会表现 - 它会破裂吗？ - 此外，如果调度程序运行并发现它必须在特定时间（例如下午 6:00）发送 1000 条通知，它会不会，如果没有中断，那么它会在通知中引入太多延迟 - 比如说通知应该在下午 6:00 发送的内容将在下午 6:05 左右发送
在思考问题的同时，我们提出了下一个提议的架构：
建议拱门。 2：
在这种架构下，我们想为什么不把调度的事情转移到 SQL Server 上，并创建一个每分钟运行一次的作业（因为，没有人会在一分钟内设置调度 - 也就是说 - 一个人会设置一个安排在下午 6:35，而不是下午 6:35:09）
此外，此过程仅涉及 SQL CLR 对象和通知中心，不涉及 Azure 移动服务或 Azure SQL DB。
所以，这个过程将是这样的：
- 将安排一个 SQL Server 作业每隔一分钟运行一次
- 如果作业在下午 5:00 开始，它将查看下午 5:01 是否有任何预定通知 - 如果是，则开始发送通知
- 如果没有，那么静默结束，然后在下午 5:01 重新调用自己，看看是否有任何针对下午 5:02 的计划
- 以同样的方式继续，直到明确停止
主要问题是这会奏效吗？
为每分钟安排一个作业是否是一种好习惯（即使 SQL Server 有该选项）？
如果作业在下午 5:01 发现它有 10,000 条通知要在下午 5:02 发送，该怎么办？是否能够发送所有这些
顺便说一句，在这个体系结构中，我们将使用 Azure 通知中心发送通知，并且会有一个 SQL CLR 函数说，“发送通知”，它将挂接到这个通知中心，并在被调用时发送通知计划的作业。
请向我推荐其他链接，这些链接将指向更好的处理方式。如果我们必须一次发送太多通知，我的客户非常担心我们将如何处理通知
非常感谢所有回答/评论的人！ :)
【问题讨论】：
标签： sql-server architecture notifications job-scheduling azure-notificationhub