设想一下这样的情形：
var txn = new DatabaseTransaction();
var entry = txn.Database.Load<Entry>(id);
entry.Token = "123";
txn.Database.Update(entry);
PublishRabbitMqMessage(new EntryUpdatedMessage { ID = entry.ID });
// A bit more of processing
txn.Commit();现在，EntryUpdatedMessage的使用者可能会在提交事务txn * 之前 * 收到此消息，因此将无法看到更新。
现在，我知道RabbitMQ本身确实支持事务，但是我们不能真正使用它们，因为我们为每个发布创建一个新的IModel，并且在我们的场景（ASP.NET Web应用程序）中使用每线程模型确实很麻烦。
我曾考虑过在提交DB事务时发布一个消息列表，但这确实是一个很糟糕的解决方案。
正确的处理方法是什么？
1条答案
按热度按时间v6ylcynt1#
RabbitMQ鼓励您使用发布者确认而不是事务。事务的性能不佳。
在任何情况下，事务在面向服务的体系结构中通常都不能很好地工作。最好采用一种“最终一致”的方法，在这种方法中，失败可以在以后重试，重复的幂等消息被忽略。
在您的示例中，我将在发布消息之前执行数据库更新并提交。当发布者确认返回时，我将更新数据库记录中的一个字段，以指示消息已发送。然后，您可以让一个清理器进程随后出现，检查未发送的消息并将其发送出去。如果消息确实通过了，但由于某种原因确认或后续数据库写入失败，你会得到一个重复的消息，但这并不重要，因为你已经把消息设计成了幂等的。