Microsoft SQL Server 2005 的 XML 最佳实施策略

引言

SQL Server 2005 的一个主要成就是可以实现可靠、可扩展且功能完善的数据库应用程序。 与 .NET Framework 2.0 公共语言运行库 (CLR) 的集成使开发人员可以将重要的业务逻辑与存储过程合并，而 T-SQL 和 XML 中的新增功能扩展了数据操作的可用范围以及开发人员可用的存储功能。另一个重要功能是 SQL Server Service Broker，它为数据库应用程序增加了可靠、可扩展、分布式异步功能。

为什么要编写异步排队操作？

在开发 SQL Server 2005 时，我们与成功开发过大型可扩展数据库应用程序的人员进行了交谈。结果发现他们几乎所有的应用程序中都有一个或多个操作是以异步排队方式执行的。股票交易系统中的结算活动是排队的，这样可以在后台进行结算，在前端处理其他交易。订单输入系统中的发货信息放在一个排队中，稍后将由另一台服务器（通常位于其他位置）上运行的发货系统读取。旅行预订系统在客户填写完路线后再进行实际的预订，并在预订完成后发送确认电子邮件。在所有这些示例中，许多工作都是通过异步方式完成的，从而提高了系统的响应速度，因此用户无须等待工作完成就可以收到响应。

在大多数大型系统中，经过仔细分析后都可以发现，许多处理都可以通过异步方式完成。虽然应用程序中的排队任务无须立即完成，但系统必须确保这些任务能够可靠地完成。Service Broker 使异步排队任务的执行可靠并且易于实现。

使应用程序中的部分任务异步执行的另一个优势是这些任务的处理工作可以在资源可用时完成。如果订单输入系统中的发货任务可以从队列中执行，发货系统就无需具有处理峰值订单负载的能力。在许多订单输入系统中，峰值订单率可能是平均订单率的两倍或三倍。由于订单输入系统必须具有处理峰值负载的能力，因此大量处理能力在很大一部分时间内都处于闲置状态。如果在出现峰值时对异步任务进行排队并在空闲时执行，将显著提高系统的利用率。

为什么排队应用程序难于编写？

既然异步排队应用程序具有许多优势，为什么不以这种方式编写所有应用程序？这是因为编写异步排队应用程序相当困难！许多尝试在应用程序中使用数据库表作为队列的开发人员发现，实际操作远比想象的困难。作为队列的表中包含多个进程，包括同时插入、读取和删除几条记录。这将带来并发问题、降低系统性能并导致频繁死机。尽管许多开发人员都成功地解决了这些难题，但实际操作却非常困难。Service Broker 通过使队列成为 SQL Server 2005 数据库中的第一级数据库对象解决了这些问题。编写队列的大多数难题都已解决，因此开发人员可以专注于编写异步应用程序，而不是编写排队基础结构。本文的其余内容将讨论编写排队应用程序涉及到的难题，并解释 Service Broker 如何帮助您解决这些难题。

消息的完整性

在许多异步排队应用程序中，排队的消息实际上是有价值的业务对象。例如在订单输入系统中，如果将发货信息放入队列中以便稍后处理，那么丢失排队的数据将意味着无法按订单发货。许多可靠的消息传送系统都将消息存储在文件系统中，因此磁盘驱动器的损坏将导致消息丢失。Service Broker 将消息存储在隐藏的数据库表中，因此 SQL Server 为保护数据而提供的所有数据完整性功能同样可用于保护排队的消息。如果使用数据库镜像进行故障恢复，当因数据库故障而转移到第二个数据库后，所有消息都会转移到第二个数据库中，这样 Service Broker 应用程序将继续运行而不会丢失任何数据。

多读取器队列

多读取器队列是一种扩展异步应用程序的最有效的方式。为证明这一点，我将通过大家都熟悉的两个示例说明如何进行排队。

在杂货店排队

大多数杂货店都可以增设多个队列。每个收银台都有其自己的队列，因此要购买某些商品，您需要选择一个队列。如果您像我一样，大多数时候选择的队列中都有一个满载而归的顾客排在您前面，他/她购买的很多商品都需要核实价格，而且要使用第三方远期支票进行付款。在轮到您结帐之前，可能在您开始排队时还没有出门的顾客都已经为他们购买的商品付完了款。这个例子说明了使用多个队列时的一个问题：即，如果排在前面的任务需要很长时间才能处理完，后面的任务将无法得到及时处理。

使用多个队列的另一个主要问题是，添加一个队列后需要在各队列之间重新分配任务，在队列之前来回移动任务可能会浪费很多时间。还以上面的杂货店为例，当一个新的收银台开始工作时，想象一下许多顾客推着购物车蜂拥而至的场面吧。

在机场排队

虽然航空公司并非高效率的典范，但大多数售票点的工作效率都比杂货店要高，这是因为多个票务代理都在为一个队列服务。由于只有一个队列，因此您不必担心排错了队。如果某个乘客占用了较长的时间，其他票务代理仍可以继续为其他乘客服务（假定有多个票务代理）。

具有多个读取器的一个队列也可以轻松扩展。如果队列太长，可以增加代理而不必打断队列。某些代理也可以在接待完当前乘客后离开，而不会在队列中造成混乱。

尽管可能会偏离主题，但我们仍以机场队列为例来说明基于队列的应用程序的另一个常见问题。假定排在一个队列中的几个人属于一个团队，比如说，我和我的家人正在登记准备去旅行。再假定我的家人由于到达时间不同而分散排在一个队列中。如果我们希望坐在一起，那么代理将需要预留一排坐位。如果我和妻子同时来到不同的票务代理处，则我可能预订了第 4 排的 5 个座位，而我的妻子预订了第 47 排的 5 个座位。这是多读取器队列的一个主要问题：即，如果在不同的线程中同时处理相关的消息，将很难进行协调。请想象一下同时处理订单标题和订单内容的情景。处理订单内容的读取器会认为没有相关的订单标题，因为订单标题还未读入数据库。为了正确工作，订单内容必须多次重新查找订单标题，以确保订单标题只是被延迟而不是不存在。

[1] [2] [3] [4] [5] [6] [7] [8] 下一页

复制本页网址和标题，发送给你QQ/Msn的好友一起分享

上一篇:数据库编程经验两则

下一篇:微软SQL Server 2000 Reporting Services