浅析SQL Server 2005中的主动式通知机制

　　本文中，我想通过一个简单的Windows桌面表单示例（基于SQL Server 2005的范例数据库AdventureWorks）向读者展示SQL Server 2005中这种新的主动地通知工作机理。由于Visual Studio 2005的革命性变化，你可以极为容易地把这个例子更改到Web应用程序场合下。

　　一、引言

　　在开发多人同时访问的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内的消息持续保留着，较高级的前端应用程序会自己处理这个消息。

　　如前所述，由于SQL Server 2005的通知机制在基层上依赖于Services Broker，所以要发出通知的数据库必须让Services Broker启动。Services Broker利用SQL Server 2005所提供的队列创建异步通知。而通知其实就是一组Services Broker内置好的服务（也即是标准的消息、发送的消息及发送消息的规则等等）。下图2中，我们通过SQL Server Management Studio中的对象资源管理器窗口查看每一个范例数据库AdventureWorks的“Services Broker”节点下属相关的设置情况：

图2：SQL Server 2005在Services Broker中已经准备好主动式通知设置情况

　　前面已经提到，我们想通过SQL Server 2005的范例数据库AdventureWorks进行试验；所以，若要让程序能够收到通知，必须先启动该数据库的相应服务，同时还要允许登录的帐户订阅这种查询通知。下面SQL语句实现创建相应的设置：

--启动Service Broker服务支持
ALTER DATABASE AdventureWorks SET ENABLE_BROKER
--
--我们无法直接在sp_dboption中（使用“EXEC sp_dboption AdventureWorks”语句）
--看出某个数据库是否启动了Service Broker服务
--需要观察sys.databases的is_broker_enabled字段才知道是否已经启动—使用如下语句：
SELECT * FROM sys.databases
--允许某个账号订阅查询
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO [YourComputerNameUserName]

　　三、示例分析

　　有了上面的分析和相应的SQL设置后，现在让我们来观察一个使用SQL Server 2005主动式通知机制的Windows桌面应用程序的示例。程序相应表单的设计界面如下图3所示：

图3：表单的设计界面

Public Class DeskNotification
Dim conn As New SqlConnection(ADONET20.My.Settings.AdventureWorksConnection)
Delegate Sub PopulateList()
Private Sub DeskNotification_Load(ByVal sender As System.Object， ByVal e As
System.EventArgs) Handles MyBase.Load
SqlDependency.Start(ADONET20.My.Settings.AdventureWorksConnection)
‘取得初始数据
ListProducts()
End Sub
Private Sub productListBox_SelectedIndexChanged(ByVal sender As System.Object，
ByVal e As System.EventArgs) Handles productListBox.SelectedIndexChanged
Dim strItem As String = productListBox.SelectedItem.ToString
lblId.Text = strItem.Substring(0， strItem.IndexOf("-") - 1)
txtPrice.Text = strItem.Substring(strItem.IndexOf(":") + 1)
End Sub
Private Sub btnUpdate_Click(ByVal sender As System.Object，
ByVal e As System.EventArgs) Handles btnUpdate.Click
Dim cnn As New SqlConnection(ADONET20.My.Settings.AdventureWorksConnection)
If lblId.Text = "无" Then
MessageBox.Show("请选择某一条记录")
Exit Sub
End If
cnn.Open()
Dim cmd As New SqlCommand( _
"UPDATE Production.Product SET ListPrice=" & txtPrice.Text & " WHERE
ProductID=" & lblId.Text， _
cnn)
cmd.ExecuteNonQuery()
cnn.Close()
End Sub
Sub OnDependencyChanged(ByVal sender As Object， ByVal e As SqlNotificationEventArgs)
'SqlDependency对象的OnChanged事件触发时
'要执行的业务逻辑
Dim dR As DialogResult
dR = MessageBox.Show("数据已经完毕，要更新数据吗？"， e.Info.ToString， _
MessageBoxButtons.YesNo， MessageBoxIcon.Question)
If dR = Windows.Forms.DialogResult.Yes Then
'由表单的主线程实现数据更新
Try
Me.Invoke(New PopulateList(AddressOf ListProducts))
Catch ex As Exception
MessageBox.Show(ex.Message)
End Try
End If
End Sub
Public Sub ListProducts()
'重新装载数据
' SqlDependency设置后，仅会注册一次的事件通知
Dim dep As New SqlDependency()
'设置SqlDependency对象的OnChanged事件发生时要调用哪个事件处理器
AddHandler dep.OnChange， AddressOf OnDependencyChanged
'限制查询的范围，避免太大的范围的大量用户都影响到这个范围内的数据以致使SQL Server
'频繁地触发通知
Using cmd As New SqlCommand( _
"SELECT ProductID， Name， ListPrice FROM Production.Product " & _
"WHERE ProductID BETWEEN @Start AND @End"， conn)
With cmd
.Parameters.Add(New SqlParameter("@Start"， Data.SqlDbType.Int))
.Parameters.Add(New SqlParameter("@End"， Data.SqlDbType.Int))
.Parameters(0).Value = txtStart.Text
.Parameters(1).Value = txtEnd.Text
End With
'自动帮助我们设置SqlCommand的Notification属性所需的SqlNotificationRequest对象
'可以通过Debug来观察SqlCommand对象执行前后的关系
dep.AddCommandDependency(cmd)
productListBox.Items.Clear()
conn.Open()
Dim reader As SqlDataReader = cmd.ExecuteReader()
While reader.Read()
productListBox.Items.Add(reader("ProductID") & " - " & _
reader("Name").ToString & ": " & reader("ListPrice").ToString)
End While
End Using
conn.Close()
End Sub
Private Sub DeskNotification_FormClosing(ByVal sender As System.Object，
ByVal e As System.Windows.Forms.FormClosingEventArgs) Handles MyBase.FormClosing
SqlDependency.Stop(ADONET20.My.Settings.AdventureWorksConnection)
End Sub
End Class

　　在这个例子中，我们首先在Global.asax文件内的Application_Start事件加入通过SqlDependency类的静态方法Start启动监听。注意，这个Start方法需要传递数据库连接字符串。它将完成如下相应操作：

　　◆打开一条新的不经过数据库连接池的到SQL Server 2005的连接；

　　◆在服务器上创建一个新的队列，并赋予唯一名称；

　　◆在该队列上创建一个唯一名称的服务；

　　◆在服务器上创建一个新的存储过程，在客户端不再监听队列时，清除掉上述的临时创建的各种对象；

　　◆侦听队列所收到的更改通知。

　　在上面的例子中，尽管你可以通过SqlCommand实例中的SQL更改记录，但并没有自动更新列表框内的记录数据，而是在收到SQL Server记录改变的通知后，通过事件触发指到OnDenpedencyChanged函数调用主线程重新执行ListProducts方法，从相关数据表读取更新后的记录来重设列表框的内容。

　　四、何时使用主动式通知机制

　　查询通知是针对于并不经常改变的数据而设计的。最好把它应用于服务器端的应用程序(例如ASP.NET或remoting)而不是客户端应用程序(例如Windows表单应用程序)。记住，每一个通知请求都要在SQL Server中注册。如果你拥有大量的都有通知请求的客户端应用程序，那么这可能会导致你的服务器产生资源问题。鉴于此，微软推荐，对于客户端应用程序，你应该限制使用查询通知的最大并行用户数不多于十个。

　　对于大规模应用程序来说，查询通知可能是一种强有力的帮助，而不用简单地添加越来越多的服务器以满足要求。设想，有一家大型的为成千上百万用户提供在线软件更新服务的软件公司。不是使每一个用户的更新操作都触发服务器上的另一个查询来确定需要哪些组件，而是能够缓冲查询结果并且可以直接从该缓存中服务匹配的查询。

　　对于较小规模的情况而言，下拉式列表框是另一种典型的数据集；此时该数据集更新的次数一般不如请求的次数多。产品列表、州列表、国家列表、供应商、销售人，甚至更多不太需要频繁改变的信息正是使用上述通知机制的较好候选。

　　五、小结

　　尽管查询通知是.NET 2.0中最重要的特征之一，但是目前它仍然难与其它优秀特征（例如ASP.NET中的泛型或UI魔术等）相衔接。然而，无论你使用它来防止针对于含有数百个项的下拉列表框的连续的反复查询，还是使用它来管理基于Web的上百万的客户端计算机的更新，它都能有效地帮助你减少资源开支。就其最简单的应用来看，借助于ASP.NET OutputCache指令（或通过在你的Web应用程序的中间层或Web服务中构建一种复杂缓冲的机制），查询通知可以成为创建可扩展的具有响应性的应用程序的强有力的协作开发工具。

　　本文基于SQL Server 2005 Express Edition调试通过。另外，尽管查询通知可以与SQL Server Express（SSE）一起使用，但是SSE数据库必须是一个命名的实例(命名的实例是安装选项之一)。