当消息队列事务中未使用MS DTC时
本文关键字：MS DTC 未使用 消息 队列 事务 | 更新日期: 2023-09-27 18:27:40
我正在创建一个设计，以使用MSMQ进行扩展来处理大量作业。每个作业都会被处理，并且数据库会针对该作业Id进行更新，表示该作业已完成。如果出现错误，则应返回队列。所以，我需要一个transactional MSMQ。现在，我可以处理这个作业，更新数据库记录可能会因为任何原因而失败。在这种情况下，我也需要将作业放回队列中，以便可以重新尝试并成功保存回数据库。这意味着我需要启用MS DTC来管理数据库服务器上的事务。
我正在读Pro MSMQ的书，书中提到"对于大多数应用程序来说，根本不需要事务。存在过度使用事务的趋势，并不必要地影响整个系统的性能。在决定使用事务之前，分析整个系统的ACID属性要求和性能影响。"。
我不明白哪些情况不涉及database更新。从队列中提取的任何记录都不需要在某个地方进行处理和更新吗？我认为大约90%的系统将需要这种类型的功能。如果它是一个中间层队列，将它传递给另一个队列或类似的东西，我就会得到它，但对于处理管道中的最后一条记录，难道不总是需要MS DTC吗？
想法？
编辑：-全文：
事务性消息传递提供了很多好处，例如完整性和消息顺序，而不是非事务性消息，但是使用事务性消息传递所付出的性能代价是巨大的。只有在绝对必要的情况下才使用内部交易维护队列中消息的顺序。外部交易提供跨多个资源管理器。当存在具有多个数据库和消息的大规模分布式系统队列，以及消息之间的事务完整性这些资源管理器之间的交换至关重要。开销使用外部交易时发生的费用要高得多而不是由内部消息队列事务引起的。对于在大多数应用程序中，根本不需要事务。有一个过度使用事务并影响整个系统不必要。在决定使用交易之前，分析整个系统的ACID属性需求从而对性能产生影响。
正如书中所说，在这些事务中登记的主要问题是，锁定多个资源会牺牲高容量时的性能。在不失去一致性的情况下，还有其他方法可以让你实现目标。一致性、可用性和分区容差之间总是存在权衡（阅读CAP定理），您需要决定系统的哪些属性才能成功满足业务需求。
要在没有事务的情况下解决问题，您可以Peek消息，而不是将消息从队列中弹出，如果处理成功，则弹出消息并丢弃它。如果处理失败，则将消息移动到错误队列中。错误队列可以自动重试（这可能是暂时性问题）。应主动监控错误队列，以确保系统正确处理，即如果错误队列超过阈值或以一定速度增加，则需要触发警报。
请注意，正如您所评论的，这种方法不适用于具有多个处理器的单个队列。这将适用于对数据和消息进行分区并将处理器绑定到队列的情况。
例如，我正在为一家连锁零售商进行集中销售处理。我可以说，我在QA队列处理我们东海岸的零售商，在QB队列处理我们西海岸的零售商。我有一个绑定到处理器PA的队列QA（可以是多个exe或单个exe中的线程）和绑定到QB的处理器PB。通过这种方式，可以为系统中的不同实体按顺序处理消息。
关键是选择正确的数据分区方案，以便工作均匀分布。