sql-server - Sql Server Service Broker 对话组

Question

有人可以解释一下服务代理中的对话组吗？

目前，我正在使用服务代理将消息从一台 SQL 服务器发送到另一台。在发送服务器上，我尝试关联消息，以便它们在接收端串行处理。根据文档， session 组似乎非常适合此目的，但在接收服务器上，消息被分配到与我发送消息时指定的 session 组不同的 session 组。

我在网上进行了搜索，发现这种行为似乎是有意为之的( http://social.msdn.microsoft.com/forums/en-US/sqlservicebroker/thread/baf48074-6804-43ab-844a-cb28a6dce02b/ )，但后来我对( http://msdn.microsoft.com/en-us/library/ms178624.aspx )中的语法的有用性感到困惑

WAITFOR( 
  GET CONVERSATION GROUP @conversation_group_id FROM [dbo].[ReceiveQueue]
)

如果 session 组没有遇到来自发件人的消息，并且使用相同 session 组 ID 发送的消息在接收端没有相同的 session 组 ID，那么上面的代码有什么意义？

Answer 1

session 组是用于锁定的本地原语。 session 组内的消息没有顺序保证，并且 session 组不会通过网络传输。

对话中的消息顺序由 Service Broker 保证。因此，为了保留处理中相关消息的顺序，请在同一对话中发送它们。

需要对话组来对一组彼此相关的对话进行分组。 GET CONVERSATION GROUP 和 RECEIVE 动词都保证它们将锁定整个 session 组，从而防止任何其他线程处理相关消息。例如，考虑一个旅游网站。它收到一条请求预订假期套餐的消息。因此，它发起与酒店预订服务的对话并发送预订房间的请求，它发起与航空预订服务的对话并请求旅行预订，它发起与汽车租赁代理服务的对话并请求汽车预订。它创建的这三个新 session 都与收到请求的初始 session 位于同一组中(应用程序已在所有 3 个 session 上使用 BEGIN DIALOG 的 WITH RELATED_CONVERSATION 子句)。然后它提交并继续处理队列中的消息。随后，这 3 个相关请求的响应开始出现，时间几乎是随机的。假设酒店的响应是第一位的。该消息被应用程序接收，并继续使用酒店的响应来更新请求的状态。与此同时，航空公司响应进来。如果允许另一个线程接载它，它会尝试更新同一请求的状态，从而导致阻塞甚至死锁正在处理酒店响应的线程。当酒店响应被处理时，线程提交并因此解锁整个 session 组，允许任何线程(包括其本身)获取航空公司响应并处理它。