sql-server - SQL Server服务代理: How to structure Conversations for a simple queue scenario?

Question

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

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

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

走这两条路线的后果是什么？

另外，在第一种情况下，我似乎需要做一些结束对话，以便 Sql Server 能够在内部清理资源。对于何时放置这些内容的正确位置有任何指导吗？ (或者依赖对话最终超时可能会更好吗？)

Answer 1

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

这是最简单的部署，启动并运行它将确保您拥有坚实的基础。当生产者将工作项排队时，不要偷工减料并在发起者端结束对话，这是 fire-and-forget and has several draw backs .

如果您有很高的性能要求(每秒超过 200 个请求)，那么您必须开始更明确地管理对话。我有一篇博客文章 reusing conversations for performance reasons 。在接收方面，我建议阅读 Writing Service Broker Procedures .

我还有一个博客条目，它几乎可以满足您的需要，尽管它没有安排工作项目，而是启动一个自定义过程:Asynchronous procedure execution .

如果您决定使用激活上下文中的工作项，从而利用激活的良好 self 平衡功能，那么您需要 understand the EXECUTE AS context under which activation occurs .