concurrency - 特定的 NServiceBus Sagas : Concurrent Access to Saga Data Persisted in Azure Table Storage

Question

此问题涉及当 saga 数据保留在 Azure 表存储中时对 saga 数据的并发访问。它也是在 Prefer 的文档中找到的引用信息:http://docs.particular.net/nservicebus/nservicebus-sagas-and-concurrency

我们注意到，在并发执行处理程序的单个 saga 中，对 saga 数据的修改似乎是在“最后一个发布对 azure 表存储的更改获胜”的情况下进行的。当将 NSB 与 Azure 表存储结合使用作为 Saga 数据持久层时，这是预期的行为吗？

示例:

1. Saga Data 中的整数属性，假设当前 = 5
2. 在此传奇中，5 个命令由同一处理程序的 5 个实例处理
3. 每个命令处理程序都会递减 saga 数据中的整数属性
4. 处理这 5 条消息后，saga 数据中整数属性的最终值实际上可能为 4 - 如果每条消息均由 saga 的新实例处理，可能位于不同的服务器上，每个服务器都有一个指示整数的 saga 数据副本属性为 5，将其减至 4，然后回传。我刚才描述的是极其并发的示例，但是如果同时处理 5 条消息中的任何一条，整数很可能会大于 0，saga 数据整数属性唯一达到 0 的时间是 5 个命令碰巧执行时连续。

此外，由于 Azure 表存储支持乐观并发，是否可以像使用 Raven 作为持久性技术时为 RavenDB 启用此功能一样，在表存储中启用此功能？

如果这是不可能的，建议的处理方法是什么？目前，我们遵循的范式是，saga 中任何可能同时处理多个消息的处理程序都不允许修改 saga 数据，这意味着我们对 saga 消息的协调是通过 saga 外部的方式完成的，而不是使用 Saga 数据正如我们最初的预期。

Answer 1

与特定支持人员合作后 - 上述症状最终成为 NServiceBus.Azure 中的缺陷。此问题已由 NServiceBus.Azure 5.3.11 和 6.2+ 中的 Pspecial 修复。我个人可以确认更新到 5.3.11 解决了我们的问题。

仅供引用，此问题的一个明显迹象是抛出以下异常但未得到处理。

Failed to process message Microsoft.WindowsAzure.Storage.StorageException: Unexpected response code for operation : 0

异常的详细信息将指示“UpdateConditionNotSatisfied” - 指乐观并发检查。

感谢 Pspecial 的 Yves Goeleven 和 Sean Feldman 诊断并解决了此问题。