当传奇数据保留在Azure表存储中时，此问题与并发访问传奇数据有关。它还是在特殊文档中找到的参考信息：http://docs.particular.net/nservicebus/nservicebus-sagas-and-concurrency
我们注意到，在同时执行一个saga的处理程序中，对saga数据的修改似乎是在“最后一个将更改发布到Azure表存储获胜”的场景中进行的。将NSB与Azure Table Storage一起用作Saga数据持久层时，这是否是预期的行为？
例：
Saga Data中的Integer属性，假设当前为5
5个命令由同一处理程序的5个实例处理
每个命令处理程序都会减少saga数据中的integer属性
处理这5条消息后，saga数据中integer属性的最终值实际上可以为4-如果每个消息都是由saga的新实例处理的，则可能在不同的服务器上，每个服务器都有saga数据的副本，指示integer属性为5 ，将其减少到4，然后重新发布。我刚刚描述的是一个极端并发的示例，但是如果同时处理5条消息中的任何一条，则整数可能会大于0，saga数据整数属性唯一达到0的时间是5条命令恰好执行时连续地。
另外，由于Azure表存储支持开放式并发性，是否有可能像使用Raven作为持久性技术时为RavenDB启用该功能一样，将其用于表存储？
如果这不可能，那么推荐的处理方法是什么？当前，我们正在订阅一个范式，即传奇中的任何可能同时处理多个消息的处理程序都不允许修改传奇数据，这意味着我们对传奇消息的协调是通过传奇外部的手段而不是使用传奇数据来完成的。就像我们最初打算的那样。
最佳答案
在特殊支持下工作-上述症状最终成为NServiceBus.Azure的缺陷。此问题已由NServiceBus.Azure 5.3.11和6.2+中的特定修补程序修复。我可以亲自确认更新到5.3.11解决了我们的问题。
作为参考，此问题的明显迹象是以下异常被抛出而不得到处理。
无法处理消息
Microsoft.WindowsAzure.Storage.StorageException：意外的响应
操作码：0
异常的详细信息将指示“ UpdateConditionNotSatisfied”-指乐观并发检查。
感谢Particular的Yves Goeleven和Sean Feldman诊断并解决了此问题。
关于concurrency - 特殊的NServiceBus Sagas:并发访问Azure表存储中持久存在的Saga数据，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/28489201/