问题标签 [service-broker]

我将 Service Broker 用作作业引擎的消息传递队列。创建作业时，系统会为它们提供一个 Guid，用于跟踪作业的进度。鉴于此，是否可以在 Service Broker 中创建一个使用给定 Guid 而不是自己创建的对话框？

我注意到一些对话没有关闭，保持在 CONVERSING 状态。奇怪的是，队列被配置为一次只处理 1 条消息。然而，在实践中，有 2 个对话处于 CONVERSING 状态，一个确实在做一些工作，另一个似乎被卡住了。

我正在使用的一件事是单个队列和服务，它不同于通常的服务代理实现（使其更像是独白而不是对话）。我开始激活SP：

我有一个包含 250 万行的表，每行都有一个 xml 类型的列。当消息到达另一个队列（触发队列）时，所有记录都应该被删除并排入 sqlserver 服务代理队列。性能非常重要，现在它太慢了。实现这一目标的最佳方法是什么？

目前我们在 triggerqueue 上使用一个激活的 sp，它在 while(@message <> null) 循环中执行：

有没有更快的方法来解决这个问题？

顺便说一句：在有人问之前：我们需要从表开始，因为它填充了之前计算的合并语句的输出

我有一个分布式系统，其中将有 1 个 SQL Server、1-n 个处理服务器和 1-n 个数据供应商（网络上的硬件设备）。提供的数据需要在进入关系数据库结构之前进行处理 - 由处理服务器执行（作为 Windows 服务 - .net 代码来解析数据、处理数据并将其插入到关系结构中。）
处理潜在的加载而不减慢数据提供者的速度，我想实现一个队列，但我不确定我是否想将 MSMQ 服务器的复杂性添加到组合中。MSMQ 有没有很好的替代方案，比如使用 DB（平面表）作为队列？.NET 是否为 DB 队列提供任何开箱即用的支持，或者是否有其他可靠队列选项？
谢谢

编辑：（11 月 29 日，晚上 11:30）
听起来 SQL 服务代理（SSB）可能会成功。
http://www.netframeworkdev.com/windows-communication-foundation/service-broker-vs-msmq-as-reliable-queueing-mechanism-63981.shtml

编辑：（11 月 30 日，上午 7 点 45 分）
在此主题上找到另一个非常有用的链接：http:
//social.msdn.microsoft.com/Forums/en-US/sqlservicebroker/thread/52687510-0852-44f3-bfcd-83610d1c1b9a
我还在研究将提供的数据的最大/最小大小。在他们的脑海中，有人知道 MSMQ 和/或 SSB 可容纳的最大大小吗？
MSMQ：4MB 消息大小
SSB：2GB 消息大小

编辑：（11 月 30 日，上午 8 点 15 分）
这里的 MSMQ 和 SSB 之间进行了很好的比较：
消息队列的好策略？

我正在运行安装了外部激活器的 SQL Server 2005 标准版。我在 SSMS 选项卡中有以下代码：

当我运行它时，我会在结果窗格中得到预期的输出。在 EATrace.log 中，我收到错误消息“通知消息类型 //abc/XYZ/RequestPostMessage 是意外的。”

EAService.config 中没有任何内容告诉 EA 预期的消息类型。为什么我收到此错误，而不是 EA 执行其配置文件中指定的应用程序？我的合同设置不正确吗？

** 以下新增部分：**

根据 Remus 的建议，我添加了以下内容：

但是当我将配置文件中的 NotificationService 名称从“//abc/xyz/TargetPostService”更改为“//abc/xyz/NotificationPostService”时，我收到错误“ERROR = 31, The notification service //abc/xyz/启动服务时，EATrace.log 中的 NotificationPostService 不存在”。但是，该服务在 sys.services 中列出。

** 错误 31 已解决，现在的问题是我的应用没有被调用 **

我使用了 Service Broker 团队博客中的示例应用程序，添加了用于调试目的的日志记录。它会在运行后立即写入日志文件，然后再执行其他任何操作。我已经通过从 VS2010 运行它来测试它并且工作正常，但是当我使用这个问题开头的代码发送消息时，不再创建。因此我知道我的应用程序不是由 EA 运行的。我如何诊断为什么会发生这种情况？我的 EAService.config 文件中的路径是正确的。这是整个文件：

我使用了正确的 QueueName 吗？此文件中是否还有其他可能的错误？我还能做些什么来诊断这个？这是发生的对话：

我在各种 MSDN 页面和 SQL Server 博客中阅读过“通常”在 Service Broker 数据库中需要主密钥。

实际上，在尝试接收消息时，我收到以下应用程序事件日志消息：

Service Broker 需要访问数据库“MDR_REPLICATION_Z”中的主密钥。错误代码：26。主密钥必须存在，并且需要服务主密钥加密。

让我感到困惑的是，为什么当我所有的 CONVERSATION 的 ENCRYPTION = OFF 时会发生这种情况。

有没有办法在 ENCYRPTION 为 OFF 的单个数据库内部使用 Service Broker，而无需创建数据库主密钥？

即使我指定 Receive Top(25) 等，我一次也只能收到一条消息出列。不确定我在存储过程中做错了什么？可能是一些微不足道的事情，但我没有看到问题。

存储过程：

知道我做错了什么吗？

谢谢，

乙

我们正在尝试确定我们是否正确使用 Service Broker 并从中获得最大性能。我们一直在调整我们的 SB 对话和处理，从 3000/分钟到 8000/分钟，但 CPU 一直保持在 100%。此外，在某些日子 SB 队列保持为空，但在类似流量的日子，队列可以备份 500k。

该机器是四核（16 核），没有 HT，32gb RAM 和 26gb 分配给 SQL Server，启用了 AWE。

SQL Server 2008 SP1（无 CU），企业版。Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (X64) 2009 年 3 月 29 日 10:11:52 版权所有 (c) 1988-2008 Microsoft Corporation Enterprise Edition (64-bit) o​​n Windows NT 6.1 (Build 7600: )

消息被插入到服务代理队列中，该队列提取消息组并通过 CLR 运行它们，CLR 解析 XML（不是简单的解析，唉）并插入到表中。CLR 比我们的 T-SQL 代码快得多。

每个调度程序平均有 35 个可运行任务

我们每晚进行统计/索引维护。

我们已将服务器 MAXDOP = 1 设置为尝试提高性能。

我们将 tempdb 文件的数量增加到 64 个以避免 SGAM 争用，结合 TF1118 似乎已经停止了 TEMPDB 争用。

查看 sys.dm_os_waiting_tasks，我们通常有大约 60 个任务在 THREADPOOL 上等待，其他类型的任务很少。

我们的信号等待是 70%（资源等待 = 30%）。

我们已验证 TokenAndUserPermCache 保持在 20mb 以下。

查看 sys.dm_os_latch_stats，我们在 1 分钟内看到 40-200k BUFFER 锁存器，这些锁存器主要位于 sysdesend 和我们用来处理 Dialogs 的用户表上。

我们还看到高 SOS_SCHEDULER_WAIT，这也表明 CPU 压力。但这是因为 CLR 异常忙碌，还是因为 Service Broker 开销？我很乐意提供代码 - 让我知道我需要在这里发布什么。

提前致谢。

我已经在我的开发环境中运行 Service Broker 几个月了，并且性能非常好，达到每秒 1000 条消息（足以满足我的需求）。

我也一直在我的真实生产环境的一个缩减副本上运行，其中涉及一个转发实例，今天第一次通过它推动了一些负载，结果很糟糕！我试图了解我所看到的，但有点挣扎，所以我想我会把它拿出来看看是否有人可以提供帮助。

首先，通过转发器从头到尾传递消息。然而，当我推送几千条消息时，我看到批量发送 20 到 100 条消息，然后延迟一两分钟。消息最终被成功处理。

查看 Store 上的队列（初始发送者），有成千上万条等待转发的消息正在流出。

安全设置如下：

当我打开分析器时，我看到很多错误：

转发实例的一些示例：

在我的“中央”目标实例上：

任何人都可以通过指出我可以进行的一些检查来帮助我，或者可能是我错过的一些明显的事情。我知道我有什么问题，但就是看不出是什么。

编辑 - 2011 年 1 月 1 日 - 更多信息：关于此的更多信息 - 我们将消息转发实例排除在外，并立即看到了巨大的改进 - 2000 条消息在几秒钟内交付。

该架构使用传输安全性，因此我们目前正在尝试切换到对话安全性，因为我们已经了解到传输安全性/转发会损害性能。我们希望 Dialog 安全性能够以某种方式优化转发实例需要解密的内容，从而提高性能。

星期一的第一件事我想关闭传输层（在发起者和转发者之间）的加密，看看这是否是我们的瓶颈发生的地方。这是否可能会导致我们的通信开销很大，或者一个转发实例不应该产生如此大的瓶颈？

我正处于 .NET 服务的规划阶段，该服务不断处理传入消息，其中涉及各种转换、数据库插入和更新等。作为一个整体，该服务庞大而复杂，但它执行的单个任务很小，简单，定义明确。

出于这个原因，并且为了便于将来扩展，我想将服务拆分为几个较小的服务，这些服务基本上执行部分处理，然后再将其传递给链中的下一个服务。

为了实现这一点，我需要某种中间消息传递系统，它将消息从一个服务传递到另一个服务。我希望以这样一种方式发生这种情况，即如果链中的链接崩溃或短暂脱机，则消息将开始排队并在目的地恢复联机后得到处理。

我一直对这类事情使用消息队列，但最近才知道 SQL Service Broker 似乎做了类似的事情。SQLSB 是这种情况的可行替代方案吗？如果是，我是否会通过使用它而不是标准消息队列来看到任何性能优势？

谢谢