msmq - 寻找能够提供完全 ACID 和什么都没有的消息总线实现

Question

任何人都知道提供对一致性保证的精细控制的消息总线实现？ Full ACID 太慢，没有 ACID 太错误。

我们目前正在使用 Rhino ESB 包装 MSMQ 进行消息传递。在分布式事务中使用持久的事务性消息传递时，MSMQ 可以在等待 I/O 完成时阻止提交相当长的时间。

我们的消息分为两大类:业务逻辑和非规范化。后者占消息总线流量的很大比例。

业务逻辑消息需要完全 ACID 的保证，而 MSMQ 已证明对此非常足够。

非规范化消息:

必须耐用。

在原始事务完成之前不得处理。

可以多次处理。

即使原始事务回滚，只要遵守 2)，也可以处理。

(在某些特定情况下，持久性要求可能会放宽，但将这些情况作为规则的异常(exception)进行识别和处理会增加复杂性。)

所有非规范化消息都在进程中处理，因此不需要 IPC。

如果进程重新启动，则可以假定所有事务都已完成(提交或回滚)，并且必须恢复所有尚未处理的非规范化消息。重放已经处理过的非规范化消息是可以接受的。

据我所知，处理事务的消息传递系统倾向于在完整的 ACID 或没有之间进行选择，而 ACID 会带来性能损失。在某些情况下，根据发送的消息数量，我们看到对 TransactionScope#Commit() 的调用需要长达几百毫秒的时间。

使用非事务性消息队列会导致消息在原始事务完成之前被处理，从而导致一致性问题。

我们系统的另一部分具有类似的一致性要求但复杂性较低，已经在使用类似于事务日志的自定义实现，并且概括地说，对于这个用例当然是一种选择，但我宁愿不实现低延迟, 并发的、持久的、事务性的消息传递系统，如果我不需要的话:P

如果有人想知道，要求非规范化消息的持久性的原因是检测不同步和修复不同步分别可能非常困难和非常昂贵。人们确实会注意到某些地方出现轻微错误并且页面刷新无法修复它，因此忽略不同步不是一种选择。

Answer 1

这不是您正在寻找的确切答案，但 Jonathan Oliver 撰写了大量关于如何避免在消息传递中使用分布式事务并保持事务完整性的文章:

http://blog.jonathanoliver.com/2011/04/how-i-avoid-two-phase-commit/
http://blog.jonathanoliver.com/2011/03/removing-2pc-two-phase-commit/
http://blog.jonathanoliver.com/2010/04/idempotency-patterns/

不确定这是否对您有帮助，但是，嘿。