想象一下这样的情况:
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 应用程序)中,对于每个发布并拥有每线程模型真的很麻烦。我想过在提交数据库事务时发布消息列表,但这是一个非常糟糕的解决方案。
处理这个问题的正确方法是什么?
最佳答案
RabbitMQ 鼓励您使用发布者确认而不是交易。交易表现不佳。
在任何情况下,事务在面向服务的体系结构中通常都不能很好地工作。最好采用“最终一致”的方法,可以在以后重试失败,并忽略重复的幂等消息。
在您的示例中,我将在发布消息之前进行数据库更新并提交。当发布者确认返回时,我将更新数据库记录中的一个字段以指示消息已发送。然后,您可以稍后进行清扫程序,检查未发送的消息并在途中发送。如果消息确实通过,但由于某种原因确认或后续数据库写入失败,您将收到重复消息。但这无关紧要,因为您已将消息设计为幂等的。
关于transactions - 将 RabbitMQ 与数据库事务集成,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/17810112/