【问题标题】:Service Broker message flow服务代理消息流
【发布时间】:2018-08-31 10:39:36
【问题描述】:

我在两个位置有两台不同的服务器。我需要使用异步数据交换。

  • 服务器 A 是我们的数据服务器,我们在此处存储客户信息。
  • 服务器 B 是我们的处理服务器,我们处理生产。

服务器 B 上的每个生产操作都有一个生产组。我需要做的是:

  1. A 向 B 发送一条消息,其中包含一个问题:该组今天计划执行哪些操作 (GUID)。
  2. B 必须用今天安排的 XML 操作列表来回答。
  3. A 必须使用要取消的操作的 XML 列表来回答
  4. B 必须取消操作并结束对话

我的问题是:解决这个问题的正确方法是什么?我可以使用一个合同在一个对话框中执行此操作吗?我应该吗?

有了这样的合同:

CREATE CONTRACT [GetScheduledContract] 
AUTHORIZATION [xxx]
(GetScheduledOutCalls SENT BY INITIATOR,
ReturnScheduledOutCalls SENT BY TARGET,
DeleteScheduledOutCalls SENT BY INITIATOR)

或者我应该将任务分成不同的合同和对话吗?

【问题讨论】:

    标签: sql-server tsql sql-server-2012 service-broker


    【解决方案1】:

    作为 MVP,你所拥有的对我来说似乎很好(即,如果一切顺利,它就会起作用)。有几点:

    1. 考虑在结束对话之前再添加一条来自目标的回复“操作已成功完成”。收到后,发起人也可以关闭他们的结束。
    2. 如果其中任何操作明确无法完成(例如,在您的步骤 4 中,请求是删除不存在的内容或删除导致外键违规),会发生什么情况?我会添加某种错误消息类型 (sent by any),让任何一方都可以告诉对方“嘿……出了点问题”。
    3. 如果这些操作中的任何一个隐式无法完成(例如,消息永远不会被传递),会发生什么?对方可能因为某种原因没有回应。以某种方式构建,至少可以检测到这一点并发出警报。

    【讨论】:

    • Re #1,我认为发起者在收到结束对话(或 SB 错误)消息而不是收到结果消息时结束对话会更好。带有SENT BY TARGET 的消息类型可用于成功和错误结果(每个或所有取消操作)。目标通常不在乎发起方是否有事情发生,因为这通常是由消费者提供的。稳健的 SB 设计面临的最大挑战可能是使用异步消息处理和/或监控不愉快的路径。
    • 在回复:#1,这就是我的意思。如果不是这样,我很抱歉。正如 OP 所说的流程,发起者可能在发送订单取消请求后结束了他们的对话。通过拥有目标 ACK,它可以进行更稳健的处理。
    • 完全同意目标方应先结束对话。 Fire and forget 是应该避免的反模式。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-11-05
    • 1970-01-01
    • 2018-11-26
    • 1970-01-01
    • 2012-06-05
    • 2011-06-08
    相关资源
    最近更新 更多