TxSelect 和 TransactionScope [英] TxSelect and TransactionScope

查看:190
本文介绍了TxSelect 和 TransactionScope的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

最近,我一直在使用 C# 上的 RabbitMQ 作为实现发布/订阅的一种方式.我更习惯于使用 NServiceBus.NServiceBus 通过在 TransactionScope 中登记 MSMQ 来处理事务.其他事务感知操作也可以加入相同的 TransactionScope(如 MSSQL),因此一切都是真正的原子.在下面,NSB 引入了 MSDTC 进行协调.

Recently, I've been checking out RabbitMQ over C# as a way to implement pub/sub. I'm more used to working with NServiceBus. NServiceBus handles transactions by enlisting MSMQ in a TransactionScope. Other transaction aware operations can also enlist in the same TransactionScope (like MSSQL) so everything is truly atomic. Underneath, NSB brings in MSDTC to coordinate.

我看到在 RabbitMQ 的 C# 客户端 API 中有一个 IModel.TxSelect()IModel.TxCommit().这适用于在提交之前不向交换发送消息.这涵盖了将多条消息发送到需要原子的交换的用例.但是,有没有一种好方法可以将数据库调用(比如 MSSQL)与 RabbitMQ 事务同步?

I see that in the C# client API for RabbitMQ there is a IModel.TxSelect() and IModel.TxCommit(). This works well to not send messages to the exchange before the commit. This covers the use case where there are multiple messages sent to the exchange that need to be atomic. However, is there a good way to synchronize a database call (say to MSSQL) with the RabbitMQ transaction?

推荐答案

据我所知,没有办法将 TxSelect/TxCommit 与 TransactionScope 进行协调.

As far as I'm aware there is no way of coordinating the TxSelect/TxCommit with the TransactionScope.

目前我采用的方法是使用带有持久消息的持久队列来确保它们在 RabbitMQ 重启后仍然存在.然后当从队列中消费时,我读取一条消息做一些处理,然后将一条记录插入到数据库中,一旦所有这些完成,我 ACK(nowledge) 消息并将其从队列中删除.这种方法的潜在问题是消息最终可能会被处理两次(例如,如果消息被提交到数据库,但在消息可以被确认之前说到 RabbitMQ 的连接已断开),但对于系统来说我们正在构建我们关注吞吐量.(我相信这被称为至少一次"方法).

Currently the approach that I'm taking is using durable queues with persistent messages to ensure they survive RabbitMQ restarts. Then when consuming from the queues I read a message off do some processing and then insert a record into the database, once all this is done I ACK(nowledge) the message and it is removed from the queue. The potential problem with this approach is that the message could end up being processed twice (if for example the message is committed to the DB but say the connection to RabbitMQ is disconnected before the message can be ack'd), but for the system that we're building we're concerned about throughput. (I believe this is called the "at-least-once" approach).

RabbitMQ 站点确实表示使用 TxSelect 和 TxCommit 会显着降低性能,因此我建议对这两种方法进行基准测试.

The RabbitMQ site does say that there is a significant performance hit using the TxSelect and TxCommit so I would recommend benchmarking both approaches.

无论采用何种方式,您都需要确保您的消费者能够处理可能被处理两次的消息.

However way you do it, you will need to ensure that your consumer can cope with the message potentially being processed twice.

如果您还没有找到它,请查看 RabbitMQ 的 .Net 用户指南 这里,特别是第 3.5 节

If you haven't found it yet take a look at the .Net user guide for RabbitMQ here, specifically section 3.5

这篇关于TxSelect 和 TransactionScope的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆