SQL Server 2005里面何时使用主动式通知机制

【独家特稿】一、引言

在开发多人同时访问的Web应用程序（其实不只这类程序）时，开发人员往往会在缓存策略的设计上狠下功夫。这是因为，如果将这种环境下不常变更的数据临时存放在应用程序服务器或是用户机器上的话，可以避免频繁地往返访问数据库—而数据库访问是要符出昂贵代价的。以往在低版本的SQL Server（SQL Server 2000及以前版本）中，当需要提供数据库内他人更新后的状况时，主要是通过轮询数据库机制来提供对数据库的不断查询；也可能是借助于存储于数据库表格中的触发器或者通过消息队列方式来达到通知目的。如今，作为微软.NET 2.0战略的重要组成部分之一的SQL Server 2005首次引入了主动式通知（Query Notification）机制。SQL Server 2005在所使用数据更改时，会主动地通知你。这种新的设计模式会让你在系统数据未更新时，减轻浪费网络来回轮询的负担，从而有可能极大地提高系统性能。

本文中，我想通过一个简单的Windows桌面表单示例（基于SQL Server 2005的范例数据库AdventureWorks）向读者展示SQL Server 2005中这种新的主动地通知工作机理。

【另注】由于Visual Studio 2005的革命性变化，你可以极为容易地把这个例子更改到Web应用程序场合下。

二、SQL Server 2005中的主动式通知

主动式通知（也称为“查询通知”），是微软ADO.NET和SQL Server小组协作开发的新成果。它允许你对数据进行缓冲并且仅在SQL Server中的数据发生变化时才发出通知；一旦接到通知，你就可以刷新相应的缓冲区或者采取其它必要的措施。

在SQL Server 2005中引入的一种新特征“Service Broker”使得查询通知成为可能。Service Broker把队列机制引入到数据库管理中，它使用一组队列与服务进行通讯，而服务反过来也知道如何往回通讯以调用相应的实体。其实，这些队列和服务都是一些与表、视图和存储过程一样的类对象。尽管完全可以在SQL Server内使用Service Broker，但是ADO.NET也知道如何与Service Broker进行通讯以触发这种机制并且从Service Broker中检索回通知。

【作者注】Service Broker是SQL Server 2005中新增加的一项重要服务，旨在为日趋流行的面向服务的架构（Service-Oriented Architecture，即“SOA”）在数据库存储级提供基础性支持。

其实，完整的通知架构还是比较复杂的。其中参与的组件可能包括：SQL Server 2005查询引擎、Service Broker、系统存储过程sp_DispatcherProc；ADO.NET的SqlNotification类（System.Data.Sql.SqlNotificationRequest）、SqlDependency类（System.Data.Sql.SqlDependency）；以及ASP.NET 2.0中新的Cache类（System.Web.Caching.Cache）等等。

下图1展示了SQL Server 2005中的主动通知机制及其与客户端ASP.NET页面交互的示意图。

图1：SQL Server 2005主动通知机制示意图

上面的运行逻辑大致如下：

（1）SqlCommand类中提供了一个Notification属性，用于存储通知相关的设置。当SqlCommand执行时，会让传递该执行需求的TDS协议附加上通知的相应信息。

（2）SQL Server 2005收到该需求后，为这个需求注册通知，并执行该需求自身的SQL语句；

（3）接下来，SQL Server 2005会监控后续执行的DML语法，并确定是否能够影响前一步返回给前端的数据集；一旦有影响，则会立即发送一个消息到Service Broker；

（4）Service Broker的队列中有消息后，可能发生如下情况：

a)Notification在前端应用程序侦听的队列中放入消息，由ADO.NET的下层自动读取消息并触发事件；

b)在Service Broker内的消息持续保留着，较高级的前端应用程序会自己处理这个消息。

[1] [2] [3] 下一页