SQL Server数据库时间可以用于同步多个客户端吗？
这是解决此问题的替代方法，而不是重复的方法。
我希望我的 Azure 角色在突然发生故障时重新处理数据。我考虑以下选择。
对于要处理的每个数据块，我都有一个数据库表行，并且我可以添加一列，表示“来自处理节点的最后一次 ping 的时间”。因此，当节点获取数据块进行处理时，它会将“处理”状态和时间设置为“当前时间”，然后节点有责任每隔一分钟更新一次该时间。然后，某个节点会定期询问“所有具有处理状态和 ping 时间大于 10 分钟的块”，并将这些块视为已放弃，并以某种方式将它们排队等待重新处理。
我有一个非常严重的担忧。上述方法要求节点具有或多或少相同的时间。看来我不应该对全球时间做出假设。
但所有节点都与同一个数据库通信。如果我使用数据库时间 - 在 SQL 请求中使用像 GETUTCDATE() 这样的函数，我将做与我计划完全相同的事情，但不是我似乎不关心节点时间是否同步 - 它们都会用到数据库的时候。
如果我使用数据库时间函数，这种方法会可靠地工作吗？
This is an alternative approach to solving this problem, not a duplicate.
I want my Azure role to reprocess data in case of sudden failures. I consider the following option.
For every block of data to process I have a database table row and I could add a column meaning "time of last ping from a processing node". So when a node grabs a data block for processing it sets "processing" state and that time to "current time" and then it's the node responsibility to update that time say every one minute. Then periodically some node will ask for "all blocks that have processing state and ping time larger than ten minutes" and consider those blocks as abandoned and somehow queue them for reprocessing.
I have one very serious concern. The above approach requires that nodes have more or less the same time. Looks like I should not make assumptions about global time.
But all nodes talk to the very same database. What if I use that database time - with functions like GETUTCDATE() in SQL requests I will do exactly the same thing as I planned, but not I seem to not care whether nodes time is in sync - they will all use the database time.
Will this approach work reliably if I use the database time functions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
作为一般规则，这种方法应该有效。如果当前时间只有一个来源，那么时间同步问题不会影响您。
但您必须考虑如果您的数据库服务器出现故障会发生什么。 Azure 会将您切换到另一台服务器上的另一个副本，在另一个机架中，并且不能保证该数据库服务器至少在时间方面与原始数据库服务器同步。
此外，如果您必须扩展数据库，这种方法无疑会给您带来麻烦。
我想我仍然更喜欢基于队列的方法。
As a general rule this approach should work. If there is only one source for the current time then time synchronisation issues are not going to affect you.
But you have to consider what happens if your database server goes down. Azure will switch you over to another copy, on another server, in another rack and this database server is not guaranteed to be synchronised at least with regard to time with the original one.
Also this approach will undoubtably get you in trouble if ever you have to scale out your database.
I think i still prefer the Queue based approach.