【问题标题】:Using SQL Server Service Broker for messaging between .NET apps使用 SQL Server Service Broker 在 .NET 应用程序之间进行消息传递
【发布时间】:2011-10-20 20:30:10
【问题描述】:

我正在考虑使用 Service Broker 在两个 .NET 应用程序之间进行消息传递,其中一个应用程序需要可靠地向另一个应用程序发送消息。我对这在发起方方面的看法有一个很好的想法。

但是,消费者应用需要从队列中加载消息,进行一些处理,然后确认处理正常。处理可能会失败,在这种情况下,我需要重试该消息。我还需要保留所有已为历史目的处理的消息。

据我所知,当我执行 RECEIVE 时,消息会从队列中删除。那么消费者应用程序在失败的情况下应该怎么做呢?再次将消息推送到队列中?我可以将消息标记为“处理中”,然后在我的任务成功完成后将其删除吗?

如何使用 Service Broker 对此进行建模?

【问题讨论】:

  • Service Broker 是一件很棒的事情——如果您需要在 SQL Server 内部或之间进行消息传递。对于两个 .NET 应用程序之间的通信,我会查看 WCF 而不是 SQL Server Service Broker...
  • 我需要一个异步队列,它是持久的。如果其中一个或两个应用程序都死了,则排队的项目不会丢失。 WCF 中有什么可以给我的吗? MSMQ 或其他分布式消息队列(不幸的是)目前不适合这个项目。
  • 为什么不能选择 MSMQ?它就在那里,每台 Windows Server 都免费提供,它与 WCF 很好地集成在一起......我相信它非常适合您的需求......
  • @marc_s,别问,我很乐意为这项工作使用正确的工具。不幸的是,我受到目前无法控制的东西的限制。

标签: .net sql-server sql-server-2008-r2 service-broker


【解决方案1】:

您可以在事务中接收并在出现错误时回滚事务。请注意,内置的有害消息处理将在给定消息的 5 次此类回滚后禁用队列。

【讨论】:

  • 每个单独的任务可能需要几秒钟才能完成。这不是不好的做法并导致队列中的争用保持事务开放这么长时间吗?
  • @driis:特别是队列和 RECEIVE 被设计为在存在长寿命事务的情况下运行良好:新消息的排队不会与 RECEIVE 事务持有的锁冲突,并发的 RECEIVE 可以继续平行线。见msdn.microsoft.com/en-us/library/ms171615.aspx
  • 如果处理真的很长,那么你应该出列,更新一些状态表,加入一个计时器,提交并开始处理。如果成功,则重置计时器。如果失败,计时器将触发,您的应用逻辑将读取保存的状态,将新计时器入队,提交并再次尝试。见msdn.microsoft.com/en-us/library/ms187804.aspx
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-04-29
  • 2011-05-17
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多