当我参加Microsoft的SQL Server 2008演示时,他们快速了解了我们正在使用的功能.事实证明,在整个演讲厅,我的公司是唯一使用Service Broker的公司.这让我感到很惊讶,因为我认为会有更多的人使用它.
我在SB方面的经验是,它的工作做得很好,但管理非常困难,而且很难得到概述.
那么,您考虑过使用Service Broker吗？如果没有,为什么不呢？你有没有去过MSMQ？SQL Server 2008中是否有任何可以让您考虑使用Service Broker的内容.
自SQL 2005发布几个月后,我一直在使用SQL Service Broker.我们在这里不停地使用它,每天通过它发送数十万条消息.
我们使用它将数据从登台表加载到生产表,以便加载登台表的服务不必等待数据实际处理,它可以返回并获取更多数据来加载.
我们使用它来排队从文件系统中删除文件.(删除行时,也需要删除该文件.)
在以前的公司,我用它来打印贷款文件和发给客户的支票.
我甚至使用Service Broker从OLTP数据库到OLAP数据库进行ETL以进行实时报告.
大多数人(尤其是DBA)不喜欢Service Broker,因为它没有任何UI.如果您想使用服务代理或者看看它在做什么,您必须实际编写并运行一些T/SQL.
我在2005年使用SB大约两年了,其中一个实现每天处理数十万条消息.我要说的是,最大的挑战并非在建筑方面,而是要了解所涉及的所有细微差别.微软的文档很少,但很少有实际例子.Remus Rusanu的博客在处理对话重用和激活存储过程调优方面确实很有帮助.我发现尽可能多地重用对话框(以及处理所涉及的所有相关锁定)以及将多个接收的消息作为一个集合处理而不是一次处理它是非常重要的.
监测SB可能是一种痛苦.你基本上依赖一堆系统视图来告诉你发生了什么.孤立的消息很痛苦.只有很多小问题可以,好吧,getcha.
除了问题,并没有那么多,我认为它确实比我预期的更好.由于SB已集成到数据库中,因此没有单独的消息队列备份到数据库之外.这在事务上都是一致的.表现很好.这是一个很好的解决方案.
我会再次使用它并继续使用它.
在我现在的公司,我们对SB的使用与其他海报的使用有所不同.我们在SQL2005中主要使用SB作为管理工具.例如,我们使用它来管理对大量不可变数据库中存在的一小组可变表的更新.所有消息都在同一实例上运行的服务之间,并且消息量非常低.
我对SB的经验是,正确设置可能有些"繁琐",正如您在问题中提到的那样,很难概述SB的状态,因为没有单一的监控工具.
尽管如此,我们发现它作为一种以可追溯和可靠的方式自动执行大量数据库管理任务的方法具有极大的价值.
京公网安备 11010802040832号 | 京ICP备19059560号-6 