对话群组只是一个本地概念，仅用于锁定：关联对话属于群组当您在一个会话上处理消息时，另一个线程不能处理相关的消息。没有关于由两个端点交换的对话组的信息，因此在您的示例中，所有发起方端点最终属于一个对话组，但目标端点每个是不同的对话组（每个组只有一个对话）。系统的行为是这样的，因为会话组被设计为解决诸如旅行预订服务的问题：当它接收到预订旅行的消息时，它必须预订航班，酒店和汽车出租。它必须发送三个消息，一个到这些服务（航班，酒店，汽车），然后响应将异步回来。当它们返回时，处理必须确保它们不由单独的线程同时处理，这将分别尝试更新行程记录状态。在消息传递中，这个问题被称为消息相关性问题。

Conversation groups are a local concept only, used exclusively for locking: correlated conversations belong in a group so that while you process a message on one conversation, another thread cannot process a correlated message. There is no information about conversation groups exchanged by the two endpoints, so in your example all the initiator endpoints end up belonging to one conversation group, but the target endpoints are each a distinct conversation group (each group having only one conversation). The reason the system behaves like this is because conversation groups are designed to address a problem like, say, a trip booking service: when it receives a message to 'book a trip', it has to reserve a flight, a hotel and a car rental. It must send three messages, one to each of these services ('flights', 'hotels', 'cars') and then the responses will come back, asynchronously. When they do come back, the processing must ensure that they are not processed concurrently by separate threads, which would each try to update the 'trip' record status. In messaging, this problem is know as 'message correlation problem'.

然而，经常会话组被部署在SSB中，仅仅出于性能原因：它们允许更大的RECEIVE结果。目标端点可以使用 MOVE CONVERSATION ，但在实践中有一个更简单的窍门：扭转对话的方向。让您的目标启动对话（分组），源在目的地启动的会话上发送其更新。

However, often conversation groups are deployed in SSB solely for performance reasons: they allow larger RECEIVE results. Target endpoints can be moved together into a group by using MOVE CONVERSATION but in practice there is a much simpler trick: reverse the direction of the conversation. Have your destination start the conversations (grouped), and the source sends its 'updates' on the conversation(s) started by the destination.

一些备注：

• 不要使用BEGIN / SEND / END的模式。您日后无法诊断任何问题，请参阅 Fire and Forget：Good for the military，but not for Service Broker conversations 。


• WITH CLEANUP在生产代码中。它用于像灾难恢复这样的行政最后手段。如果你滥用它，你拒绝SSB任何机会正确跟踪消息正确的重试交付（如果消息退出目标，无论什么原因，它将永远丢失）。


• SSB不能保证会话中的顺序，只能在一个会话中。为每个INSERT事件启动新对话不保证在目标上保留插入操作的顺序。