【问题标题】:MSMQ for persistence?MSMQ 用于持久性?
【发布时间】:2011-12-23 05:40:36
【问题描述】:

在我的项目中,我收到来自客户端的事务,然后对其进行处理并通过 WCF 将状态返回给客户端。如您所知,我必须以某种方式保存事务以用于恢复目的和持久性。

我正在考虑为此目的使用 MSMQ。当事务开始时,我会将它“保存”在 MSMQ 上(出于性能原因,数据库保存将分批进行)。

MSMQ 对此有好处吗?您知道创建持久性的更好方法吗? “备份”事务并保持高性能的最佳方式是什么?

【问题讨论】:

    标签: c# persistence msmq


    【解决方案1】:

    在选择技术时,我认为不仅要考虑能否该技术满足您的需求,还要考虑它是否设计来满足您的需求。我的意思是你应该选择最好的选项,而不是只选择看起来足够好的第一个选项。您可能可以通过日志记录或文本文件或各种其他方式解决此问题,但这并不意味着您应该这样做。

    在这种情况下我的优先顺序是

    1. 数据库
    2. MSMQ
    3. 其他一切

    如果由于某种原因无法将事务保存到数据库,那么 MSMQ 可能会在这里为您提供帮助。它应该比打开数据库连接和提交更好,但提供了一个“好的”持久层。缺点是它的代码更多,并且是您的应用程序的另一个故障点(不是如果编写得当它会失败,而是更多的代码意味着更多的错误位置)。

    您可以使用类似这样的方式非常轻松地将事务放入队列中

    private string queuePath = @".\Private$\myQueue";
    MessageQueue queue = new MessageQueue(queuePath);
    
    Message message = new Messge();
    message.Id = "messageId";
    message.Body = "my content";
    
    queue.Send(message, transaction);
    transaction.Complete();
    queue.Close();
    

    然后稍后通过查询属性检索它们:MSMQ querying for a specific message。还有很多开箱即用的其他功能,但请保持简单。

    一些相关问题:

    【讨论】:

      【解决方案2】:

      我认为您正在寻找SQL Server Service Broker。 10 年前我们用 MSMQ 所做的一切,现在都用服务代理做。效果很好。

      【讨论】:

      • Service Broker 很棒,但依赖于数据库可用性和响应时间,这可能是 OP 正在尝试解决的问题。
      • 这适用于任何事务排队系统,因此与特定产品无关。
      • @ChrisSmith 那是针对我的吗?使用提及以便我得到通知:) 在这种情况下,MSMQ 将在网络服务器本身上运行,因此没有“可用性”问题 - 如果网络服务器在线,消息存储也是如此,而数据库通常在另一台机器上运行。响应时间也很长,因为 MSMQ 在本地运行,而数据库可能在半个地球的某个地方。
      • @KirkBroadhurst:很抱歉错过了 :) 那么当您需要两个 Web 服务器时会发生什么?如果您需要扩展,沟通是不可避免的。
      • @ChrisSmith 确实如此——我们并不真正了解全貌。每个网络服务器拥有自己的队列可能就足够了——只要事务被保留在“某处”就足够了。正如我在回答中所说,我总是希望尽可能将数据库用作第一个停靠港。
      【解决方案3】:

      数据库和文件系统使用的一种流行方法称为预写日志记录。然而,这并非易事。您可以在这里找到详细信息...

      Wikipedia: Write-Ahead Logging

      【讨论】:

      猜你喜欢
      • 2019-04-30
      • 2017-01-15
      • 2014-04-27
      • 2010-10-24
      • 1970-01-01
      • 1970-01-01
      • 2016-11-04
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多