Sql server 2008服务代理数百万个队列

Question

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

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

但是,通过代理队列的工作方式,我无法在单个队列中隔离用户的消息.我只能在检索到邮件后看到.但是,我只希望它为正在调用它的用户检索消息.

因此,如果我想使用代理服务,我需要为每个用户提供一个单独的队列.

然后我最终会在经纪人服务中拥有数百万个队列.

我是否缺少代理服务的任何功能,可以允许我有一个队列但是使用过滤器检索邮件？

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

Answer 1

消息传递应用程序通常是事件驱动的,即.当消息到来时,它会激活处理消息的处理过程.Service Broker通过附加到队列的激活机制实现此功能.在这种哲学中,不需要过滤消息,因为处理总是处理队列中的"下一条消息",理想情况下,队列总是为空.因此,RECEIVE动词不提供任何过滤器.RECEIVE的WHERE子句仅限于会话和会话组,这可以帮助应用程序利用会话组锁定概念,而不是过滤我们的某些消息.

虽然排队只不过是用伪装名称伪装的普通(内部)表格,但它们带有一些隐含的行李,会让数百万人知道一个坏主意:

• 每个队列必须至少具有与之关联的服务.服务在运行时成本上更重要,因为它们与消息路由相关联,因此它们消耗启动时间(扫描数据库并创建tempdb隐藏实例路由表),tempdb空间(所述路由表)和运行时内存(与路由关联的缓存内存结构).它们还会引起一些CPU开销(路由算法决定数百万候选者).
• 如果激活与它们相关联,队列可以变得更加"自己".每个队列都有一个运行时对象Queue Monitor,它将占用内存和CPU,请参阅http://rusanu.com/2008/08/03/understanding-queue-monitors
• 您将需要至少一个会话才能到达队列,并且实时,活动,对话可能会发生一些开销.
• 队列对象与RECEIVE动词相关联,更重要的是与动词相关联WAITFOR(RECEIVE).WAITFOR阻止服务器上的工作线程,并且sp_configure 'max worker threads'在您放置WAITFOR每个队列之前,您将耗尽很长时间.

从配置/监视要求的角度来看,队列/服务比普通表更加"活跃".当我这样说时,我有两个问题:毒物信息检测可以触发和禁用你的队列,你将很难留意一百万个队列(它可以而且应该是自动化的,但仍然是).第二个问题是,如果由于某种原因,消息通过传输队列延迟,可能会发生这样的问题:当传输恢复时,唤醒数百万个会话会表现得非常糟糕(milleage可能会有所不同,很大程度上取决于你的SQL版本/ SP级别)正如某些问题在SQL 2K5 SP3后修复了).

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

在你的情况下,因为我希望我明确表示为什么拥有数百万的队列是一个坏主意.您的消息来自何处(本地与远程),以及您为何开始考虑Service Broker？如果不知道所有细节,我会说最好的选择是有一个队列,一个激活的程序,在到达时处理所有消息,并将每个用户的相关信息存入普通表,可以通过以下方式正确过滤每个用户都有自己的数据.

披露:我是Service Broker团队的前成员,并负责维护SSB博客