SQL Server 2005 Service Broker 初探

核心提示： •将消息传送功能内置在数据库中还有一些显著的性能优势，•正如前面所述，SQL Server 2005 Service Broker 初探(8)，事务性消息不要求两阶段提交，•消息更新、状态更改和数据更新都记录在同一事务日志中，但由于传入消息进行了排队，因此接收

•

将消息传送功能内置在数据库中还有一些显著的性能优势。

•

正如前面所述，事务性消息不要求两阶段提交。

•

消息更新、状态更改和数据更新都记录在同一事务日志中，因此在提交事务时只需写入单个日志。

•

可靠的消息传送通常将消息从传送队列传送到接收队列。如果 Service Broker 检测到接收队列与传送队列位于同一数据库实例中，则消息直接放入接收队列中，从而节省了额外的输入/输出并减少了事务提交的次数。

四、Service Broker 编程

Service Broker 功能通过 SQL Server 中的新对象启用，这些新对象可以由一组 T-SQL 扩展来创建和操作。为了数据库程序员的方便，使用了他们熟悉的用于配置其他数据库对象的 CREATE、ALTER 和 DROP DDL 语句来配置 Service Broker 应用程序。用于创建 Service Broker 对话以及在对话中发送和接收消息的命令是 Transact SQL 语言的 DML 扩展。接收命令的语法与选择命令相似，它返回包含消息的行集，就像选择命令返回包含行的行集一样。熟悉 Transact SQL 编程的开发人员会发现学习 Service Broker 编程非常容易。用于为 Service Broker 编程的客户端 API 与用于为所有数据库编程的 API 相同，例如 OLEDB、ODBC、ADO、ADO.NET 等等。下面是 Service Broker 使用的对象。

队列

Service Broker 使用队列在消息发送程序和消息接收程序之间提供松散耦合。发送程序可以使用 SEND 命令将消息放到队列中，然后应用程序继续操作并依靠 Service Broker 来确保消息到达其目标位置。

队列允许较大的计划灵活性。例如，发送程序可以发送多条消息以供多个接收程序并行处理。接收程序可能在消息发送很长时间后才处理消息，但由于传入消息进行了排队，因此接收程序可以按其自己的速率处理消息，而且发送程序无须等待接收程序完成处理便可继续操作。