如何将Azure SQL与Azure BLOB存储同步

没有任何工具可以确保数据库记录和Azure Blob存储之间的引用完整性。

作为一种选择，您可以有一个工作角色来保持文件与数据库的同步（但这里会有一个延迟）。

另一种有争议的干净方法是只有一个用于添加/删除blob文件的入口点，并在那里处理与数据库的同步。

我同意scripni的观点，你也可以投票支持以下问题：

http://www.mygreatwindowsazureidea.com/forums/34192-windows-azure-feature-voting/suggestions/469736-event-handler-support-for-blob

如果blob存储有事件，您可以知道何时插入事件，然后更新数据库。您也可以有一个工作者角色，或者只是cron作业，前提是每隔一段时间查询blob存储并相应地更新SQL。

没有现成的方法可以做到这一点，所以您需要自己编写。我发现这个文件监视器示例很有用：http://ben.onfabrik.com/posts/monitoring-files-in-azure-blob-storage

2022更新正如评论中所指出的，在这个答案发布后的十年里，这个链接已经消失了。折返机在这里：https://web.archive.org/web/20130629015900/http://ben.onfabrik.com/posts/monitoring-azure blob存储中的文件

考虑到自2012年以来Azure的许多变化，这是否仍然是解决这个问题的最佳方法是非常值得怀疑的。

在Azure平台上实现事务的一种方法是使用队列。将消息放入队列，只有在成功处理后才能删除该消息。

这样，如果任何操作失败，您可以在下次看到消息时尝试纠正这种情况。

我的解决方案有一个像scripni建议的单一入口点，并添加了一种类似事务的方法。

我使用数据库作为整个事务的预写日志。

1） 将数据库记录标记为"shouldBeDeleted"=true。

2） 试着删除这些斑点。

3） 如果出现错误并且Blob没有被删除，那么您仍然有记录，并且您知道应该删除它们所指向的Blob。您可以稍后再次尝试删除它们，更重要的是，您可以忽略读取查询中的记录，就像使用软删除方法一样。

4） 如果Blob已删除，则现在可以删除记录。

5） 如果失败，这些记录仍被标记为"shouldBeDeleted"，您可以忽略它们并稍后进行清理。

对我来说，主要的好处是，我不必仅为此目的创建一个工作者，而且更改是即时的，而不是依赖于同步周期在记录未同步时留下一个窗口。

您可以用几乎相同的方式为插入/更新实现相同的想法。

*有点晚了，但我相信问题仍然是当前的，其他问题也遇到了。