MSMQ 的持久性?
在我的项目中,我收到来自客户端的事务,然后对其进行处理并通过 WCF 将状态返回给客户端。如您所知,我必须以某种方式保存事务以用于恢复目的和持久性。
我正在考虑使用 MSMQ 来实现此目的。当事务开始时,我会将其“保存”在 MSMQ 上(出于性能原因,数据库保存将批量进行)。
MSMQ 适合吗?你知道有什么更好的方法来培养毅力吗? “备份”交易并保持高性能的最佳方式是什么?
In my project I receive a transaction from the client then process it and return a status back to the client via WCF. As you know I have to somehow save the transaction for recovery purposes and persistence.
I am thinking of using MSMQ for that purpose. When the transaction starts I will "save" it on MSMQ (database save will occur in a batch for performance reasons).
Is MSMQ good for that? Do you know of better way to create persistence? What is the best way to "backup" the transaction and keep high performance?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
在选择技术时,我认为不仅要考虑该技术能否满足您的需求,还要考虑它是否设计来满足您的需求,这是有帮助的。我的意思是,您应该选择最好的选项,而不仅仅是第一个看起来足够好的选项。您可能可以通过日志记录或文本文件或各种其他方式来解决此问题,但这并不意味着您应该这样做。
在这种情况下,我的首选顺序是
如果由于某种原因无法将事务保存到数据库,那么 MSMQ 可能可以在这里为您提供帮助。它的性能应该比打开数据库连接和打开数据库连接更好。提交还提供了一个“良好”的持久层。缺点是代码更多,并且是应用程序的另一个故障点(并不是说如果编写正确就会失败,而是更多的代码意味着更多的错误地方)。
您可以使用类似的方法非常轻松地将事务放入队列中
,然后通过查询属性稍后检索它们: MSMQ 查询特定消息。还有很多其他开箱即用的功能,但要保持简单。
一些相关问题:
When picking a technology I think it's helpful to consider not only can the technology meet your needs, but also whether it was designed to meet your needs. By this I mean that you should choose the best option rather than just the first option that seems good enough. You could probably solve this problem with logging or text files or various other means, but that doesn't mean you should.
My order of preference in this situation would be
If it isn't possible to save transactions to database for whatever reason then MSMQ can probably help you here. It should perform better than a opening a database connection & committing yet provides a 'good' persistence layer. The downside is that it's more code and another point of failure for your application (not that it will fail if written properly, but more code means more places for bugs).
You can throw your transactions into a queue very easily using something like this
and then retrieve them later through querying properties: MSMQ querying for a specific message. There's a lot of other functionality out of the box but keep it simple.
Some relevent questions:
我认为您正在寻找SQL Server Service Broker。 10 年前我们使用 MSMQ 所做的一切现在都在使用 Service Broker 进行。效果很好。
I think you are looking for SQL Server Service Broker. Everything that 10 years ago we did with MSMQ we now are doing with the Service broker. It works well.
数据库和文件系统使用的一种流行方法称为预写日志记录。然而,这实施起来并不容易。您可以在此处找到详细信息...
维基百科:预写式日志记录
A popular approach used by database and file systems is called Write-Ahead Logging. This is not however trivial to implement. You can find details here...
Wikipedia: Write-Ahead Logging