问并行执行DocumentDb存储过程

EN

当我第一次开始使用DocumentDB时，我也有类似的问题，在这里和DocumentDB产品经理的电子邮件中得到了很好的答案。引用：

存储过程..。获取数据库的独立快照，以获得事务支持。快照反映sproc开始执行时的当前状态(没有陈旧的数据)(非常一致)。 警告--由于存储过程是在快照上运行的，如果在执行过程中从外部世界传入新的写入，则仍然可以在sproc中读取陈旧的内容。 此外，存储过程将始终读取它们自己的写操作。 Sprocs是DocumentDB用于多文档事务的机制。当Sproc成功地完成执行时，将提交sproc写操作。如果抛出异常，sproc中完成的所有工作都会回滚。 因此，如果两个是同步运行的链式程序，他们将不会看到彼此的写作。 如果两个链式程序碰巧写入同一个文档(替换)，那么第二个链表在尝试提交写时会因为etag不匹配而失败。

由此，我继续我的设计，确保在我的写作中使用ETags，就像朱利安建议的那样。我还会自动重试每次sproc执行3次，以处理由于并行操作和其他原因而失败的情况。实际上，我从未超过3次重试(除了我的sproc有一个bug的情况)，我甚至很少得到一次重试。

从我观察到的行为来看，它将每个新的sproc执行发送到一个不同的副本，直到它用完副本，然后将它们排队等待顺序执行，所以它是并行执行和串行执行的混合体。

我通过实验学到的另一个技巧是，您最好在客户端执行纯读操作(没有写，也没有明显的聚合)，而不是在重载的系统上使用sproc。我认为DocumentDB的优势在于它可以并行地满足来自不同副本的不同读取。我使用expandScript的documentdb-utils功能对sproc代码进行了模块化，以确保我使用完全相同的代码来进行写入验证、文档内一致性和派生字段(客户端和服务器端都可以使用node.js )。即使您主要是.NET，您也可能希望使用expandScripts以模块化的方式构建sprocs。您仍然需要在构建过程中运行node.js来预处理您的脚本，或者使用Edge.NET (运行在.NET内部的节点)来动态地运行。

这将取决于您为您的收藏所选择的一致性。但是思想是，DocumentDb使用etag处理并发性，并在文档版本的快照上执行存储过程，并且只有在执行成功时才提交结果。

请参阅：https://azure.microsoft.com/en-us/documentation/articles/documentdb-faq/#develop

这个线程也可能有帮助：原子地增加Azure DocumentDB中文档中的整数