sql-server - Sql server 2008 service broker 百万队列

Question

我正在为我们的应用程序中的新功能设计线框。其中一项要求是每个用户都有一个要处理的事情列表。

我计划使用 SQL Server 2008 服务代理向用户发送待办事项通知。

但是根据代理队列的工作方式，我无法在单个队列中为用户隔离消息。我只能在检索到消息后才能看到。但是，我只希望它为调用它的用户检索消息。

因此，如果我想使用代理服务，我需要为每个用户创建一个单独的队列。

然后我最终会在代理服务中拥有数百万个队列。

我是否缺少代理服务的任何功能，这些功能可以让我拥有一个队列但使用过滤器检索消息？

SQL Server 2008 代理服务可以处理数百万个队列吗？这样做可以吗？

Answer 1

消息应用程序通常是事件驱动的，即。当消息到来时，它会激活处理该消息的处理过程。 Service Broker 通过附加到队列的激活机制来实现这一点。在这种哲学中，不需要过滤消息，因为处理总是处理队列中的“下一条消息”，并且队列在理想情况下始终为空。因此，RECEIVE 动词不提供任何过滤器。 RECEIVE 的 WHERE 子句仅限于对话和对话组，这是帮助应用程序利用 conversation group locking 的一种手段。概念，而不是过滤我们的某些消息。

尽管队列只不过是伪装在一个花哨名称下的普通(内部)表，但它们携带着一些暗示，这将使拥有数百万个成为一个坏主意:

每个队列必须至少有一个与之关联的服务。服务在运行时成本上有点重量级，因为它们与消息路由相关联，因此它们消耗启动时间(扫描数据库并创建 tempdb 隐藏实例路由表)、tempdb 空间(所述路由表)和运行时内存(与路由相关的缓存内存结构)。它们还会引起一些 CPU 开销(用于路由算法在数百万个候选之间做出决定)。

如果激活与队列相关联，队列会“自行”变得更重。每个队列都有一个运行时对象，队列监视器，它将消耗内存和 CPU，见 http://rusanu.com/2008/08/03/understanding-queue-monitors

您将需要至少一个对话才能到达队列，并且实时、活跃的对话可能会产生一些开销。

队列对象与 RECEIVE 相关联动词，更重要的是，使用 WAITFOR(RECEIVE) . WAITFOR在服务器上阻塞一个工作线程，你将用完 sp_configure 'max worker threads'在您放置 WAITFOR 之前很久很久在每个队列上。

此外，从配置/监控需求的角度来看，队列/服务比普通表更“活跃”。当我说这个的时候，我想到了两个问题: poison message detection可以触发和禁用您的队列，您将很难关注一百万个队列(它可以而且应该自动化，但仍然如此)。其次是如果消息由于某种原因延迟通过 transmission queue 时可能发生的问题。 :当传输恢复时，唤醒数百万个对话会表现得非常糟糕(里程可能会有所不同，很大程度上取决于您的 SQL 版本/SP 级别，因为某些问题在 SQL 2K5 SP3 后已修复)。

Service Broker 的设计主要考虑分布式应用程序的问题(即解决 DCM/COM+、Corba、Remoting 等 Unresolved 问题)。但它是否经常部署在本地，完全包含在一个 SQL 服务器实例甚至数据库中，以利用排队行为和激活机制。如果您查看 SSB 的唯一原因是利用队列，那么我想说的是使用 SSB 队列与构建自己的用户表支持队列之间的比例为 50/50，如果您愿意，则倾向于构建自己的队列拥有专业知识(即，您知道如何解决用户表支持的队列带来的许多死锁问题)。如果您还利用激活，那么 SSB 具有更大的吸引力，如果您实际上是在进行远程消息传递，那么显然是最佳选择。

在您的情况下，因为我希望我清楚为什么拥有数百万个队列是一个坏主意。您的消息从哪里发出(本地与远程)，您为什么要考虑从 Service Broker 开始？在不知道所有细节的情况下，我想说最好的选择是有一个队列，一个激活的过程，它在所有消息到达时处理所有消息，并将每个用户的相关信息存放在一个普通表中，可以通过以下方式正确过滤每个用户都有自己的数据。

披露:我是 Service Broker team and maintain the SSB blog的前成员