Concurrency 特定NServiceBus Sagas：对Azure表存储中持久化的Saga数据的并发访问

这个问题是关于在Azure表存储中持久化saga数据时对saga数据的并发访问。它还参考了特别是公司文件中的信息：

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

例如：

Saga数据中的Integer属性，假设当前为5

在本系列中，5个命令由同一处理程序的5个实例处理

每个命令处理程序递减saga数据中的integer属性

在处理这5条消息之后，saga数据中integer属性的最终值实际上可能是4—如果每条消息由saga的新实例处理，可能在不同的服务器上，每个服务器都有一个saga数据副本，指示integer属性为5，将其减至4，然后进行后期备份。我刚才描述的是一个非常并发的示例，但是如果同时处理5条消息中的任何一条，则整数很可能会大于0，saga data integer属性达到0的唯一时间是5条命令碰巧以串行方式执行时

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

---

如果无法做到这一点，建议采用什么方法来处理？目前，我们采用的范例是，不允许任何可能同时处理多条消息的saga处理程序修改saga数据，这意味着我们对saga消息的协调是通过saga外部的方式完成的，而不是像我们最初预期的那样使用saga数据。

azure saga存储持久器使用乐观一致性，如果多条消息同时到达，最后一条要更新的消息将引发异常，请重试并再次更正数据

这听起来像个bug，你能分享一下你的版本吗

---

PS：去年，我们解决了一个听起来与此非常类似的问题，在经过特别支持后，它已在NServiceBus.Azure 5.2及以上版本中得到解决-上述症状最终成为NServiceBus.Azure中的一个缺陷。此问题已通过NServiceBus.Azure 5.3.11和6.2+中的特定补丁解决。我个人可以确认，更新到5.3.11解决了我们的问题

作为参考，此问题的一个明显迹象是以下异常被抛出而未得到处理

无法处理消息 Microsoft.WindowsAzure.Storage.StorageException:意外响应 操作代码：0

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

---

感谢来自Special的Yves Goeleven和Sean Feldman诊断和解决此问题。

我们在NServiceBus 4.6.4版中遇到了此问题。问题124肯定是我在原始问题中描述的症状的根本原因。您是否建议我们将解决方案升级为依赖NSB 5.2？NServiceBus Azure 5.2.0应与NServiceBus.4.6.4配合使用，因此只有升级Azure软件包才能提供其他版本信息：我们也在使用NServiceBus.Azure版本6.2。这让我相信，我们已经在使用一个版本，其中包含问题124的修复程序-特别是考虑到问题已经存在一年多了。是的，修复程序也应该在6.2中，奇怪。。。我得调查一下。为了完整起见，您使用的是哪一个azure storage SDK版本？我为此提出了一个问题，并将尝试了解到底发生了什么，但根据azure storage文档和来源，我们在内部利用的替换操作应该代表我们执行乐观并发性…我们使用的是5.3.11，在Azure存储队列上运行了大约一周后，我们收到了6K条错误消息。Microsoft.WindowsAzure.Storage.StorageException连续失败：操作的意外响应代码：0