我正在使用MSMQ创建一个设计来处理大量作业以进行扩展。处理每个作业，并为该作业ID更新数据库，表明它已完成。如果错误，它应该返回队列。所以，我需要一个transactional MSMQ。现在，我可以处理该作业，并且更新db记录可能因任何原因而失败。在这种情况下，我还需要将该作业重新放入队列中，以便可以重新尝试并成功保存回db。这意味着我需要启用MS DTC来管理数据库服务器上的事务。
我正在阅读Pro MSMQ本书并提到“对于大多数应用程序，根本不需要进行交易。过度使用交易并不必要地影响整个系统的性能。在决定使用交易之前，分析整个系统的ACID属性要求和性能影响。“。
我无法理解哪些案例不会涉及database更新。是否需要在队列中处理和更新从队列中获取的任何记录？我认为90％的系统都需要这种功能。我得到它，如果它是一个中间层队列将它传递到另一个队列或类似的东西，但为了处理管道中的最后一个记录，总是不需要MS DTC？
思想？
编辑： - 全文：
交易消息传递提供了许多好处，例如消息 完整性和消息顺序，超过非事务性消息传递，但是 使用事务性消息传递所支付的性能价格是巨大的。 仅在绝对必要的情况下才使用内部交易 维护队列中的消息顺序。外部交易 提供跨越传播事务上下文的好处 多个资源管理器。有这样的交易是有用的 具有多个数据库和消息的大规模分布式系统 队列，以及消息之间的事务完整性 在这些资源管理者之间交换是至关重开销 使用外部交易时产生的更多 而不是内部消息队列事务引起的。对于 大多数应用程序，根本不需要交易。有一个 倾向于过度使用交易并影响交易的表现 整个系统不必要。在决定使用交易之前， 分析整个系统的ACID属性要求和 由此产生的性能影响。
答案 0 :(得分：0)
正如书中所说，参与这些交易的主要问题是你通过锁定多个资源来牺牲高容量的性能。您可以通过其他方式实现目标，同时不失一致性。在一致性，可用性和分区容差之间总是存在权衡（阅读CAP定理），您需要确定成功满足业务需求所需的系统属性。
要在没有事务的情况下解决您的问题，而不是将消息从队列中弹出，您可以Peek消息，如果您的处理成功，则弹出消息并丢弃它。如果处理失败，则将消息移至错误队列。可以自动重试错误队列（这可能是暂时性问题）。应主动监视错误队列，以确保您的系统正确处理，即。如果错误队列超过阈值或以某个速率增加，则需要触发警报。
请注意，正如您所评论的那样，这种方法不适用于具有多个处理器的单个队列。这将在您对数据和消息进行分区并将处理器绑定到队列的位置。
E.g。我正在为一系列零售商进行中央销售处理。我可能会说我在排队QA和西海岸排队QB处理东海岸零售商。我有一个处理器PA绑定队列QA（可以是多个exe或单个exe中的线程）和处理器PB绑定到QB。这样就可以处理消息，以便在系统中使用不同的实体。
关键是选择正确的数据分区方案，以便均匀分布工作。