让我解释一下我们已经做过的事情以及我们想要实现的目标。
现有架构:在我们当前的架构中,我们有一堆服务和一个SQL Server数据库。这些服务允许移动设备(Android / IOS)允许用户注册/登录,然后设置他的日程安排,比如说,"我需要在中午12点吃午饭"。
Android应用,在当天结束时轮询第二天设备的所有时间表,然后在第二天的适当时间显示这些时间表。
问题这种方法是,第一次,可能(据我所知)IOS不能做的事情就像把时间表保存在后台然后显示时间发生并且第二,这不是处理此问题的最佳方式 - 如果用户更改后的日程安排怎么办?'移动应用程序已完成其日程安排。
所以,我想出了一个解决这个问题的架构(建议架构1 ),并且进一步的调查还考虑了一种不同的处理方式(建议架构2 )并在下面提到这一点。你能帮助我解决我的问题,并试图了解哪种方法最有效:
这种架构非常简单。我们在此建议我们可以使用 SQL依赖关系+查询通知来了解Schedule表中的更改(其中包含所有计划,当任何用户添加,更新或删除计划时,查询通知将会被抛出)。此SQL Server单独驻留,不在云上。
我们的 Azure移动服务将为此查询通知提供处理程序,一旦收到通知,它就会更新自己的Azure SQL数据库更新的时间表然后它会提示'它自己的调度程序将自己定位到下一次重新调用 - 即 - 调度程序将检查Azure SQL DB中的调度,如果有要发送的通知,则将使用通知中心发送通知然后在必须发送通知的下重新安排自己
现在这个方法最大的问题是 - 我们非常确定我们可能会有数百甚至数千名用户同时更新他们的日程安排 - 当发生这种情况时,我不是用户如何这种架构会表现出来 - 它会破裂吗? - 此外,如果调度程序运行并发现它必须在特定时间发送1000个通知,比如说下午6:00,那么它是否会在通知中引入太多延迟 - 比如通知原本应该在下午6点发送的内容将在下午6:05左右发送
在考虑问题的同时,我们提出了下一个提议的架构:
建议Arch。 2:
在这种架构下,我们认为为什么不只是将调度事项转移到SQL服务器并创建一个每分钟运行一次的工作(因为,没有人在一分钟之内设置一个时间表 - 也就是说 - 一个人会设置一个时间安排在下午6:35而不是下午6:35:09)
此外,此过程仅涉及SQL CLR对象和通知中心,不涉及Azure移动服务或Azure SQL DB。
所以,过程将是这样的:
主要关注的是这会起作用吗?
每分钟安排作业是一个好习惯(即使SQL Server有该选项)?
如果工作在下午5:01发现它在下午5:02发送了10,000个通知怎么办?它是否能够发送所有这些
BTW,在这个架构中发送通知我们将使用Azure通知中心,并且会有一个SQL CLR函数说,“发送通知”#39;它将挂钩到此通知中心,并在计划作业调用时发送通知。请建议我指出更好的处理方式的其他链接。如果我们一次只发送太多通知,我的客户非常关注我们处理通知的方式
非常感谢所有回答/评论的人! :)
答案 0 :(得分:1)
您是否曾探索过可能使用通知中心的SendScheduledNotifications API。您可以在此处详细了解:https://msdn.microsoft.com/en-us/library/azure/dn790626.aspx。