摘要
该白皮书介绍Microsoft SQL Server 2005中的新特性——Service Broker。使用Service Broker，SQL Server内部或外部的应用程序可以利用Transact-SQL的扩展来发送和接收可靠的异步消息。

内容列表
概述
队列
对话
会话组
激活
为什么使用异步的、排队的消息？
为什么使用事务性消息？
Service Broker如何解决消息处理中的难题？
消息次序
协商
多线程
接收者管理
为什么在数据库中构建消息
会话组锁定
远程事务性消息接收处理
统一管理
直接投递到接收队列
公共语言支持
单一连接执行能力
增强的安全性
跨数据库的传输队列可见性
结论

概述
使用Microsoft SQL Server 2005的特性——Service Broker，内部或外部应用程序可以使用Transact-SQL的数据加工语言（DML）发送和接收可靠的、异步的消息。消息发送到队列中，队列可位于与发送者相同的数据库中、同一SQL Server实例的其他数据库中、或者是同一台服务器或者远程服务器的其他SQL Server实例中。
熟悉有关队列、对话、会话组和激活等关键概念将有助于您更好地理解Service Broker。这一部分将简短的讨论这些概念。

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

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

对话
Service Broker还实现了对话，对话是两个端点之间的双向消息流。对话中的所有消息都进行了排序，而且对话消息总是按照发送的顺序传送。该顺序在多个事务、多个输入线程、多个输出线程以及系统崩溃和重新启动过程中都保持不变。有些消息系统可以确保单个事务中发送或接收的消息顺序，但不能确保多个事务中的顺序，因此Service Broker对话具有独特的优势。

每条消息都包括唯一标识与它相关的对话的会话句柄。例如，某个订单输入应用程序可能同时与发货应用程序、库存应用程序和帐单应用程序打开了对话。因为每个应用程序中的消息都具有唯一的会话句柄，所以可以轻松地确定发送每条消息的应用程序。

会话组
Service Broker提供了一种机制对某一项特定任务所使用的所有对话进行编组，这种机制就是会话组。在我们前面提到的订单录入应用程序示例中，所有与处理一条特别订单有关的对话都将被编组到一个会话组中。会话组是通过会话组标识符来实现的，它包含了该会话组中所有对话的所有消息。当会话组中的任何对话接收到消息时，会话组将被接收事务所持有的锁锁住。在整个事务执行过程中，只有持有锁的线程可以接收来自会话组中对话的消息。这使得订单输入应用程序更容易编写，因为即使我们使用多线程来增强可扩展性，任何时刻一条订单都只能由一个线程进行处理。这意味着我们不需要在应用程序中处理由于多个线程同时处理一条订单而引发的问题。

会话组标识符的一个常见用途就是标记与有个特别进程相关的状态信息。如果一个进程运行一段时间后包含了许多消息，那么在整个进程中只保存一个应用程序实例是没有意义的。例如在订单输入应用程序中，可以将与某一条订单处理有关的全局状态信息存储在数据库中，当下次收到与那条订单有关的消息时再从数据库中取出状态信息。此时可以使用会话组标识符作为状态表的主键以确保快速获取与每条消息相关的状态。

激活
您可以使用Service Broker激活功能指定用于处理某个特定服务消息的存储过程。当消息到达某个服务时，Service Broker检查是否运行了可以处理消息的存储过程。如果没有运行负责消息处理的存储过程，Service Broker将启动一个，然后存储过程就可以处理消息了，直到队列为空。当队列为空时存储过程也将终止。 而且，如果Service Broker判定消息到达的速度快于存储过程的处理速度，它将启动其他的存储过程实例直到与传入消息的速度向匹配（或者达到了可配制的存储过程最大数目）。这样就可以确保始终为处理传入消息配置正确数量的资源。

为何使用异步的、排队消息？
队列允许灵活的工作调度，并因此极大地增强性能和可扩展性。要了解如果能做到这一点，回到订单输入应用程序示例。 订单的某些部分必须在在订单被确认完成之前处理完毕，例如订单标题、订单明细等。而其他部分在提交订单前实际上并不需要作处理，例如：记账、发货和库存等等。如果订单“可延缓的”部分可以通过一种有保障的、异步的方式处理，订单的核心部分就可以被处理的更快速。

异步消息还可以增加并行处理的机会。例如：如果您需要检查客户的信用卡和定购物品的可用性，那么同时启动两个进程将会提高整体的响应时间。

排队还可以均衡分布系统的处理能力，降低对服务器峰值处理能力的要求。例如：一个典型的接收订单速率看起来可能是这样的：



在每天开始时出现一个峰值，每天结束时出现另一个峰值。如果每条订单在创建时被录入到发货系统中，那么发货系统的负载看起来是这样的：



下午的峰值更高是因为此时正值外出送货的文书处理工作时间。如果发货系统通过队列连接到订单输入系统，那么就可以通过将一些工作转移到接收订单的间隙时间完成，从而使峰值变得平缓。



为何使用事务性消息？
消息代理支持事务性消息，这意味着消息是作为事务进行发送和接收的。如果事务失败了，消息的发送和接收将被回滚，直到处理消息的事务成功并提交处理结果才会生效。

事务性消息简化了基于消息处理应用程序的编写，因为您可以自由地、分散地发送和接收
任何有意义的消息，并且发送和接收直到事务提交时才会真正生效。如果事务被回滚了，任何消息发送都不会生效，那些被接收的消息将返回到队列中，这样就可以重新接收和处理这些消息了。

Service Broker如何解决消息处理中的难题？
基于消息的应用程序已经出现很长一段时间了，也有很多迫不得已的原因需要构建基于消息的应用，但为何这种应用程序却为数不多呢？答案在于基于消息的应用程序难以保证其正确性。不过SQL ServerService Broker解决了基于消息应用程序中几个最大的难题：消息次序、协商、多线程和接收者管理。

消息次序
在传统的可靠消息应用程序中很容易出现消息投递次序混乱。例如：应用程序A发送了消息1，2和3。应用程序B接收并确认了消息1和3，但是在接收消息2时遇到了错误，因此应用程序A重新发送2。但是，现在消息2是在消息3之后收到的。在传统的应用程序中，程序员需要通过编程来处理这个问题，要么使消息接收的先后次序无关紧要，要么先临时缓存消息3直到接收到消息2，这样就可以按顺序处理消息了。与传统应用程序相比，Service Broker对此进行了透明的处理，所有对话中的消息都是按照当初发送的次序接收的，不会出现消息顺序的断裂。

与此相关的一个问题就是重复投递。在前面的例子中，如果应用程序B收到了消息2，但是返回给应用程序A的确认消息丢失了，那么应用程序A将重新发送消息2并且应用程序B将接收到消息2两次。 同样地，Service Broker确保消息不会被投递两次，即使在事务执行过程中发生了掉电。

协商
消息通常是独立的实体，因此很难决定一条消息来自于哪一个会话。例如：您可能给一个库存服务发送了几千条消息并请求更新库存信息。该库存服务可能会立刻响应其中的某些消息而过了很久后才会响应其他消息，这样就很难决定某条响应消息对应于哪一条库存更新请求。

相反，通过使用Service Broker，每条消息都包含了对话句柄和会话组标识符，这样就可以很容易地决定于每一条响应消息相关的消息次序和请求消息了。（在某些消息系统中可以通过设置correlation ID来判定这些信息，但是使用对话则不需要这样做）。

多线程
在消息应用程序中最困难的问题之一就是保证多线程的队列读取器正确工作。当多个线程从同一个队列接收消息时，就有可能出现消息处理次序混乱，即使这些消息是按照顺序接收的。例如：如果一条包含了订单标题的消息被线程A接收，而包含了订单明细的消息被线程B接收，处理订单明细的事务就有可能首先尝试提交，然后遇到了参照完整性约束的失败，因为这条订单还不存在。 尽管订单明细消息将被回滚直到订单标题存在，但这样还是会导致资源浪费。

Service Broker采用某条消息被读取时在会话组放置锁的方式解决多线程问题，这样直到事务提交，其他线程将无法接收相关消息。Service Broker使多读取器的工作简便且可靠。

接收者管理
在许多可靠消息系统中，接收消息的应用程序必须在接收消息之前就被启动。大多数情况下用户必须决定在每个队列上运行的应用程序实例或线程的数目。如果接收程序的数目是固定的而消息到到达速度是变化的，就会导致大多数时间有太多或太少的队列读取程序在运行。

Service Broker在消息到达时根据需要激活队列读取程序，从而解决了接收者管理的问题。此外，如果队列读取程序崩溃或系统重启，读取器也会自动启动并读取队列中的消息。许多典型的由中间层事务处理监视器负责的应用程序管理任务，现在都是由Service Broker完成的。

为什么要在数据库中构建消息？
为什么Service Broker是数据库引擎的一部分？ 数据库外部难道没有足够可靠的消息传送系统？有许多原因可以解释为何数据库是Service Broker的最佳选择。

会话组锁定
Service Broker通过会话组锁定的方式支持多个队列读取器。但是，使用普通的数据库命令对会话组进行封锁几乎无法实现其有效性。因此Service Broker使用了一种新型的数据库锁，而且只有Service Broker命令理解这种类型的锁。

远程事务性消息接收处理
有些消息系统限制接收事务消息的应用程序只能运行在消息队列所在的服务器上。相反，Service Broker支持来自任何服务器的远程事务接收，只要服务器能够连接到队列所在的数据库。

统一管理
事务性消息系统存在的一个问题是：如果消息和数据存储在不同的位置，那么通过备份还原二者中的任何一项都有可能导致消息存储和数据库的不同步。在Service Broker中使用单一数据库存出消息和应用程序数据，从而极大地减少了错误的发生。 当您的数据、消息和应用程序逻辑都存储在一个数据库中时，您只需要对一处进行备份，在一处设置安全性、对一处进行管理。

直接投递到接收队列
由于Service Broker被集成到数据库引擎中，因此当一条消息需要发送到相同的SQL Server实例的任何数据库队列中时，消息被直接投递到接收队列中，绕过了发送队列并且极大地提高了性能。

公共语言支持
在Service Broker应用程序中，可以使用相同的开发语言和工具实现消息处理部分和数据处理部分。这极大的方便了那些熟悉Microsoft ActiveX Data Objects (ADO)和其他基于消息的数据库编程技术的开发人员。通过SQL Server 2005中对CLR (公共语言运行时) 存储过程的支持，可以使用各种编程语言编写Service Broker的存储过程，并且继续利用Service Broker统一管理的优点。

单一连接的执行能力
可以通过应用程序执行Transact-SQL语句的相同数据库连接来执行Service Broker命令。使用单一连接意味着消息事务无需成为分布式事务，而分布式事务对那些作为数据库外部应用程序的消息系统则是必须的。

增强的安全性
由于Service Broker的消息是在数据库内部处理的，因此可以方便地根据数据库对象来检查消息发送者的访问权限。如果消息系统是一个数据库外部应用程序，那么每个发送消息的用户都需要一个单独的数据库连接。数据库系统和消息系统具有相同的身份更易于正确地设置安全性。

跨数据库的传输队列可见性
由于Service Broker运行在数据库实例的上下文环境中，因此可以维护该实例上所有数据库中准备传输消息的集合视图。这种能力使每个数据库在维护自己的传输队列进行备份和管理操作的同时，还可以维护同一实例上所有数据库资源使用的公平性。这对于一个外部的消息管理器来说，即使能够做到这一点，有时也是非常困难的。

结论
Service Broker独一无二的特性以及与数据库的高度集成使之成为新一代的构建数据库应用程序松散耦合服务的理想平台。Service Broker不仅为数据库应用程序提供了异步的、排队的消息处理，也显著地增强了可靠的消息传输能力。

版权说明
该白皮书为初步文档，可能会在所述软件进行最后商业发布之前做完全修改。
该文档所含信息代表微软公司在文档出版时对所论及问题的当前看法。由于微软必须对千变万化的市场情况做出相应反应，因此本文档不应视为微软的任何承诺，且微软不保证所陈述任何信息在产品发布后的准确性。
本白皮书仅供信息参考。微软对本文件中的信息不做任何明示或默示保证。
遵守所有适用的版权法律是用户应尽的责任。下述陈述不限制任何版权，在未获得微软公司明示书面许可的情况下，不得以任何目的复制本文档任何部分或将任何部分保存或引入检索系统、亦不得以任何形式（电子、机械、影印、录制或其他方式）进行传播。
微软在文件所述主题中拥有专利权、专利应用程序、商标、版权或其他知识产权。除非在微软的任何书面许可协议中明示规定，否则对本文档的提供不得视为对任何专利权、商标、版权或其他知识产权许可的提供。
除非特别声明，本文中描述的示例公司、组织、产品、域名、e-mail地址、徽标、人物、地点以及事件均为虚构的，不应与任何实际的公司、组织、产品、域名、e-mail地址、徽标、人物、地点以及事件有任何的联系。
© 2005微软公司版权所有。
Microsoft和ActiveX是微软公司在美国和其他国家的注册商标或商标。
本文中实际公司和产品的名称可能是其相应所有者的商标。