Sql Server Service Broker:如何为简单的队列场景构建对话? [英] Sql Server Service Broker: How to structure Conversations for a simple queue scenario?

问题描述

我是 Sql Server Service Broker 新手，我正在尝试掌握为(看似)简单用例设置 Service Broker 的最佳方法:我想创建一个简单的工作队列，其中一个应用程序丢弃工作项目进入队列，并且单独的应用程序从该队列中选取工作项目并处理它们.第一个应用程序不需要从第二个应用程序获取状态消息.我希望队列存在于单个 Sql Server 实例中.

I'm a Sql Server Service Broker novice and I'm trying to grasp the best way to set Service Broker up for a (seemingly) simple use case: I want to create a simple work queue, where one application drops work items into the queue, and separate application picks up work items from that queue and processes them. There is no need for the first application to get status messages back from the second. I want the queue to live in a single Sql Server instance.

最让我困惑的是对话/对话如何与这种情况相关联.我知道您只能在对话/对话的上下文中发送/接收消息，但是由于两个应用程序之间没有来回聊天，我对何时是创建新对话的正确时间感到迷茫.两个极端的选择似乎是:

What most confuses me is how conversations/dialogs relate to this situation. I know you can only send/receive messages in the context of a conversation/dialog, but because there is no back-and-forth chatter between the two applications, I feel lost about when is the correct time to create a new conversation. The two extreme alternatives seem to be:

• 每次我将一个工作项加入队列时，我都会开始一个新的对话.因此，每个对话最终都会包含一条消息.
• 在部署时，我手动创建了一个无限生命周期的对话.当需要将工作项加入队列时，我总是将其作为单个对话的一部分发送.

走这两条路线中的任何一条会有什么后果?

What would the consequences of going either of these routes be?

另外，在第一种情况下，似乎我需要做一些 END CONVERSATION，以便 Sql Server 能够在内部清理资源.是否有任何指导何时将这些放在正确的位置?(或者依靠对话最终超时可能更好?)

Also, in the first case, it seems like I need to do some END CONVERSATIONs, in order for Sql Server to be able to clean up resources internally. Is there any guidance for when would be the correct place to put these in? (Or might it potentially be better to rely on the conversations timing out eventually?)

推荐答案

您应该从每个工作项目的对话开始.生产者(发起者)开始对话并发送描述工作项的消息，然后提交.消费者(目标)接收消息(或被激活)，检查有效负载以了解工作项详细信息，执行工作，然后结束对话并提交.生成的 EndDialog 消息被发送回发起方服务队列，发起方队列上的激活过程通过结束发起方端的对话来响应它.

You should start with each work item on its own conversation. The producer (initiator) begins a dialog and send the message describing the work item, then commits. The consumer (target) receives the message (or gets activated), inspects the payload to understand the work item details, executes the work, then ends the dialog and commit. The resulting EndDialog message gets sent back to the initiator service queue, and an activated procedure on the initiator queue responds to it by ending the dialog on the initiator side.

这是最简单的部署，启动并运行它可以确保您有一个良好的基础.当生产者将工作项入队时，不要偷工减料并结束发起方的对话，这是 一劳永逸，有几个缺点.

This is the simplest deployment and getting it up and running will ensure you have a sound foundation to build upon. Don't cut corners and end the dialog on the initiator side from when the producer enqueues the work item, this is fire-and-forget and has several draw backs.

如果您有很高的性能要求(每秒超过 200 个请求)，那么您必须开始更明确地管理对话.我有一篇关于出于性能原因重用对话的博客条目.在接收端，我建议阅读Writing Service Broker Procedures.

If you have high performance requirements (over 200 requests per second) then you'll have to start managing the conversations more explicitly. I have a blog entry on reusing conversations for performance reasons. On the receive side I recommend reading Writing Service Broker Procedures.

我还有一个博客条目，它几乎可以满足您的需求，尽管它不安排工作项而是启动自定义程序:异步过程执行.

I also have a blog entry that pretty much does what you need, albeit it does not schedule work items but instead launches a custom procedure: Asynchronous procedure execution.

如果您决定从激活的上下文中使用工作项，从而利用激活的良好自平衡功能，那么您需要了解发生激活的 EXECUTE AS 上下文.

If you decide to consume the work items from an activated context, thus leveraging the nice self balancing capabilities of activation, then you need to understand the EXECUTE AS context under which activation occurs.

这篇关于Sql Server Service Broker:如何为简单的队列场景构建对话?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！