sql-server - SQL Server Service Broker-外部激活的控制台应用程序的详尽使用示例

Question

我需要已部署使用Sql Server Service Broker外部激活机制(通过Feature Pack中的Service Broker外部激活器)的实际生产应用程序的任何人的一些指导。

当前的心态:

我的规范很简单(或者至少我这么认为)，所以我在考虑以下基本流程:

将类似于

的订单状实体插入到状态为“已确认”的Table_Orders中

SP_BeginOrder被执行并执行以下操作:

开始进行交易

从Service_HandleOrderState到Service_PreprocessOrder的DIALOG开始

将对话句柄(从现在开始在PreprocessingHandle上)存储在Orders表

的特定列中

使用PreprocessingHandle

发送消息类型为Message_PreprocessOrder的MESSAGE，其中包含订单ID

结束TRANSACTION

请注意，我并没有结束对话，我不想 "fire-and-forget" Queue_PreprocessOrder上的

事件通知会激活PreprocessOrder.exe的实例(最大并发数为1)，该实例执行以下操作:

开始SqlTransaction

从Queue_PreprocessOrder

接收前1条消息
如果消息类型为Message_PreprocessOrder(XML格式)，则为

:

使用消息正文

中的订单ID在Table_Orders中将订单状态设置为“预处理”

加载n个数据集合，这些数据集合计算出一个n-ary Carthesian product(通过Linq，AFAIK，在T-SQL中这是不可能的)来确定订单项集合

将订单项行插入到Table_OrderItems

中

使用PreprocessingHandle

发送一个Message_PreprocessingDone类型的MESSAGE，包含相同的订单ID。

结束与PreprocessingHandle有关的对话

提交SqlTransaction

使用Environment.Exit(0)退出

Queue_HandleOrderState上的

内部激活将执行以下SP(最大并发数为1):

开始进行交易

从Queue_InitiatePreprocessOrder

接收前1条消息
如果消息类型为Message_PreprocessingDone，则为

:

使用消息正文

中的订单ID在Table_Orders中将订单状态设置为“处理中”

启动一个从Service_HandleOrderState到Service_ProcessOrderItem的LOGLOG

将对话句柄(从现在开始在ProcessOrderItemsHandle上)存储在Table_Orders

的特定列中

为Table_OrderItems中的行，当前订单ID和每一行创建一个游标:

使用ProcessOrderItemsHandle

发送类型为Message_ProcessOrderItem的MESSAGE，其中包含订单项ID
如果消息类型为Message_ProcessingDone，则为

:

使用消息正文

中的订单ID在Table_Orders中将订单状态设置为“已处理”

(如果消息类型为http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog(END DIALOG)):

结束与消息

的对话句柄有关的对话

结束TRANSACTION

Queue_ProcessOrderItem上的

事件通知激活一个ProcessOrderItem.exe实例(最大并发数为1)，该实例执行以下操作:

开始SqlTransaction

从Queue_ProcessOrderItem

接收前1条消息
如果消息类型为Message_ProcessOrderItem(XML格式)，则为

:

使用消息正文中的订单项ID将Table_OrdersItems中的订单项状态设置为“处理中”，然后:

加载订单项参数

的集合

使用参数

向URL发出HttpRequest

将HttpResponse作为PDF存储在文件系统

上

如果以上子步骤中发生任何错误，请将订单项状态设置为“错误”，否则设置为“ok”

在Table_OrdersItems中执行查找以确定是否处理了所有订单项(状态为“确定”或“错误”)

(如果所有订单项都已处理):

使用ProcessOrderItemsHandle

发送类型为Message_ProcessingDone的MESSAGE，其中包含订单ID

结束与ProcessOrderItemsHandle有关的对话

提交SqlTransaction

使用Environment.Exit(0)退出

笔记:

规范指定2005年到2012年之间的MSSQL兼容性，因此:

没有 session 群组

没有 session 优先级

否POISON_MESSAGE_HANDLING(STATUS = OFF)

我正在努力实现整体流程的完整性和连续性，而不是为了加快

假定表和SP驻留在DB1中，而Service Broker对象(消息，契约(Contract)，队列，服务)驻留在DB2中，则

设置为DB2 SET TRUSTWORTHY

问题:

所描述的体系结构中是否存在主要的设计缺陷？

订单完成状态跟踪似乎不正确。有更好的方法吗？也许使用队列保留？

我的直觉告诉我，在任何情况下，激活的外部exe都不应以0以外的退出代码终止，因此Main中应该存在try{..}catch(Exception e){..} finally{ Environment.Exit(0) }。这个假设正确吗？

您将如何组织DB代码中的错误处理？错误日志表足够了吗？

您将如何组织外部exe C#代码中的错误处理？相同的错误记录
table ？

我见过SQL Server Service Broker Product Samples，但是对于我看似更简单的情况，Service Broker Interface似乎过于矫kill过正。对于更简单的Service Broker对象模型，还有其他选择吗？

是否有至少能够排放有害消息的Service Broker跨版本“便携式”管理工具？

您是否有上述任何一个不错的代码示例？

Answer 1

问:所描述的体系结构是否存在重大设计缺陷？
答:几个小津贴:
-在等待打开事务的同时等待HTTP请求完成是不好的。无论如何，您都无法实现数据库和HTTP之间的事务一致性，因此，当HTTP速度较慢时，不要冒险进行数分钟的事务扩展。典型的模式是{开始tran/receive/begin conversation timer/commit}然后不带任何DB xact发出HTTP调用。如果HTTP调用成功，则{开始xact/发送响应/结束对话/提交}。如果HTTP失败(或客户端崩溃)，请让对话时间再次激活您。您将收到一个计时器消息(无正文)，您需要从表中获取与该句柄关联的项目ID。

问:订单完成状态跟踪似乎不正确。有更好的方法吗？也许使用队列保留？
答:我对状态跟踪的一种批评是依赖于扫描订单商品，以确定当前处理的商品是最后一个商品(5.3.4)。例如，您可以添加以下信息:这是在项目状态下要处理的“最后一个”项目，因此您知道在处理项目时需要报告完成情况。 RETENTION仅在调试中或当您具有需要运行“逻辑回滚”并补偿对话错误的操作的逻辑时才有用。

问:我的直觉告诉我，在任何情况下，被激活的外部exe都不会以0以外的退出代码终止，因此最终应该尝试使用{..} catch(Exception e){..} {Environment.Exit( 0)}在Main中。这个假设正确吗？
答:最重要的是激活的进程在队列上发出RECEIVE语句。如果失败，则队列监视器may enter the notified state forever。如果我没记错的话，退出代码是无关紧要的。与任何后台进程一样，捕获和记录异常非常重要，否则，当它开始失败时，您甚至都不会知道它有问题。除了受约束的try/catch块外，UI应用程序的联播 Application.ThreadException 和UI和非UI应用程序的 AppDomain.UnhandledException 。

问:您将如何组织DB代码中的错误处理？错误日志表足够了吗？
答:我会在后面跟进。错误日志表足够恕我直言。

问:如何组织外部exe C#代码中的错误处理？错误记录表相同吗？
答:我之所以创建bugcollect.com正是因为我必须使用自己的应用程序来处理此类问题。问题不仅仅在于日志记录，您还希望进行一些汇总和分析(至少检测重复的报告)，并抑制一些“现场”部署配置事故带来的错误泛滥。说实话，如今有更多选择，例如。 exceptron.com。当然，我认为FogBugs还具有日志记录功能。

问:我已经看过SQL Server Service Broker产品样本，但是对于我看来更简单的情况，Service Broker界面似乎有些过分。对于更简单的Service Broker对象模型，还有其他选择吗？
最后，一个简单的问题:是的，这太过分了。没有简单的模型。

问:Service Broker的任何跨版本“便携式”管理工具是否能够至少排出有害消息？
答:带毒消息的问题是带毒消息的定义随您的代码the poison message is whatever message breaks the current guards set in place to detect it更改。

问:您是否有上述任何示例的代码示例？
答:不可以

还有一点:尝试避免从DB1到DB2的任何引用(例如，在DB1中激活了4.3.4并从DB2读取项目表)。这将创建跨数据库依赖关系，当a)一个DB处于脱机状态(例如，用于维护)或过载时，或者b)您添加了HA/DR的数据库镜像并且一个DB进行故障转移时，该依赖关系就会中断。即使DB1和DB2在不同的机器上(并且没有链接的服务器)，也请尝试使代码正常工作。如有必要，将更多信息添加到消息有效负载中。而且，如果以这种方式进行构造，则DB2可以位于不同的机器上，甚至可以存在多个DB2机器来扩展HTTP/PDF编写工作。

最后:这种设计将非常缓慢。我说的是每秒很慢的低速消息，涉及许多对话框/消息，而max_queue_readers 1的所有内容。您可能会接受，也可能无法接受。