SQL Server 2005 Service Broker 初探

核心提示： 如果 Service Broker 确定消息添加到队列的速度比存储过程能够处理的速度快，激活逻辑将开始其他的存储过程，SQL Server 2005 Service Broker 初探(7)，直到存储过程能够处理传入的消息或者达到了为队列配置的存储过程的最大数量，由于为队列提供服务的队列读

如果 Service Broker 确定消息添加到队列的速度比存储过程能够处理的速度快，激活逻辑将开始其他的存储过程，直到存储过程能够处理传入的消息或者达到了为队列配置的存储过程的最大数量。由于为队列提供服务的队列读取器数量随着传入消息速率的更改增大或减小，因此所有时间都将运行适当数量的队列读取器。

四、为什么要在数据库中进行消息传送？

关于 Service Broker 的一个常见问题是“为什么要将消息传送功能内置在数据库中？数据库外部难道没有足够可靠的消息传送系统？”

我希望前面的信息已经说明了为什么要在数据库引擎中内置 Service Broker，下面提供了要在数据库中传送消息的一些其他理由：

•

消息和数据的单客户端连接。除了上一部分中提到的统一编程模型，还具有一些其他显著的优势：

•

当在任何可以连接到数据库的客户端上运行时，应用程序可以通过事务接收消息。当接收程序与队列在同一计算机上运行时，许多消息传送系统只允许事务性接收。

•

与在数据库中不存储消息的消息系统不同，事务性消息传送不需要分布式事务或两阶段提交。

•

数据和消息之间集成的管理、部署和操作。用于保护和管理数据库数据的所有工具和技术同样适用于消息：

•

备份和恢复数据库还可以备份和恢复消息队列。

•

如果使用群集或数据库镜像来保护数据库以避免出现故障，则您的消息享有相同的保护。

•

由于队列具有相关的视图，因此确定队列中的操作非常简单。要了解队列中有多少条消息吗？请从队列中选择 count(*)。要了解有多少条消息尚未传送吗？请从 sys.transmission_queue 中选择 *。如果消息中包含 XML 数据，则可以使用 XQuery 进行搜索。可以使队列中的消息与状态信息甚至数据表相结合，以确定订单输入系统中特定订单的完成状态。