处理失效的延迟超时消息？

如何解决处理失效的延迟超时消息？

我是 Rebus 的新手，正在努力了解我们目前在 Azure 逻辑应用程序中使用的一些模式。当前的目标实现将最好在 Cosmos DB 中使用带有 Saga 存储的 Azure 服务总线（仍在调查该示例实现）。甚至可以使用 Mongo DB API 将 Rebus Mongo DB 与 Cosmos DB 结合使用（不过不确定是否可行）。

我们拥有的一个主要用例是事件/超时模式，在阅读了一些示例/论坛/堆栈溢出后，这种情况并不少见。棘手的部分是我们的 Sagas 更像是一个有限状态机而不是有向无环图。这主要是因为日期发生了外部变化，因此事件的超时发生了变化。

Defer() 方法不返回超时标识符，我们假设这是一个实现限制（Azure 服务总线返回一个 long）。由于我们必须忽略为现在已经改变的事件安排的超时，我们看到了一种“忽略”这些超时（因为它们无法取消）的方法，如下所示：

• 在我们自己的 Dictionary<string,Guid> 派生基类中使用 SagaData，其中键是超时消息类型的一些派生类，而 Guid 是在以下情况下给予超时消息的标识符它被创造了。我不认为这需要是一个并发字典，但这就是我在这里的原因......

• 收到事件消息后，从上述字典中删除对应的超时消息类型键；

• 收到超时消息后：

  • 如果超时消息类型键不存在或 Guid 与字典键/值不匹配，则忽略；其他
  • 过程。我们也可以在此时删除字典键。

• 发生事件重新调度时，只需添加超时消息类型/Guid 字典条目，或使用新的超时消息 Guid 更新 Guid。

这是在正确的轨道上，还是有更“正确”的方式来处理失效的超时（延迟）消息？

解决方法

你在正确的轨道上?

我不认为这需要是一个并发字典，但这就是我在这里的原因......

Rebus 允许您的 saga 处理程序处理其自己的 saga 数据副本（使用乐观并发），因此您可以自由地对 saga 数据进行建模，就好像它一次只能被一个人访问一样。