SQL Server 2005中引入的一种新特征“Service Broker”使得查询通知成为可能。Service Broker把队列机制引入到数据库管理中,它使用一组队列与服务进行通讯,而服务反过来也知道如何往回通讯以调用相应的实体。其实,这些队列和服务都是一些与表、视图和存储过程一样的类对象。尽管完全可以在SQL Server内使用Service Broker,但是ADO.NET也知道如何与Service Broker进行通讯以触发这种机制并且从Service Broker中检索回通知。
完整的通知架构还是比较复杂的。其中参与的组件可能包括: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)等等。
下图展示了SQL Server 2005中的主动通知机制及其与客户端ASP.NET页面交互的示意图。
上面的运行逻辑大致如下:
(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内的消息持续保留着,较高级的前端应用程序会自己处理这个消息。
在SQLServer2005中,SQL Server Service Broker 用于创建会话以交换消息。 消息交换在目标和发起方这两端之间进行。
使用 SqlDependency 订阅查询通知是直接的:SqlDependency 对象将管理数据库中设置通知涉及到的复杂性。建立通知后,对象便会监视实现通知的基础数据库对象,当 SQL Server 创建查询通知时,将在应用程序中调用事件处理程序。
对于应用程序接收SQL Server Service Broker通知,只能获取到对应数据库表数据做了何种更新,而无法获取更新的数据,而我们却可以利用这个通知,来做缓存依赖,来达到缓存过期的目的。
使用查询通知的应用程序必须考虑到立即出现通知的情况。服务器上的数据更改时,通知消息将发送到相应的服务中介程序队列。应用程序需要注册才能接收其他通知。因此,如果多个应用程序快速更新某个数据集,应用程序在缓存刷新后,立即可以接收通知,检索数据,然后获取另一个更新通知。编写使用查询通知的应用程序时必须考虑到此情况。如果应用程序使用不断更新的数据,则可能更适合使用另一种数据缓存策略。
使用 SqlDependency 订阅查询通知必须向SQL Server Service Broker提供制定规则的查询语句,一般来讲,必须是简单的sql查询语句(不能用*,不能用top,不能用函数,包括聚合函数,不能用子查询,包括where后的子查询,不能用外连接,自连接,不能用临时表,不能用变量,不能用视图,不能跨库,表名之前必须加类似dbo数据库所有者这样的前缀),
例如:select * from table1,select column1 from table1,select count(*) from table1 都是错误的sql查询语句,select column1 from dbo.table1 则是正确的语句。
以下以一个实际的例子(sqlDep项目)来说明如何使用ServerBroker和SqlDependency类来做缓存依赖,充分利用服务器资源和提高应用程序性能,并且封装以提供给开发人员最大的便利性,我们需要按照如下步骤操作:
1. 启动Service Broker 服务支持
use master
alter database <dbname> SET ENABLE_BROKER
需要观察sys.databases的is_broker_enabled字段才知道是否已经启动,结果为1表示已开,0表示关闭
select is_broker_enabled from sys.databases where name = '
在本例中运行以下语句:
ALTER DATABASE AdventureWorks SET ENABLE_BROKER
以启用该功能,执行时必须关闭所有可能锁表的操作和作业。
2. 为访问数据库的帐号订阅查询通知
use <dbname>
GRANT CREATE PROCEDURE TO [UserName]
GRANT CREATE QUEUE TO [UserName]
GRANT CREATE SERVICE TO [UserName]
use <dbname>
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO [UserName]
可以用下面语句查看赋给user的权限
exec sp_helprotect NULL, [UserName]
3. 在现有应用程序中增加更改通知以及缓存机制。
a) 在webconfig<configuration>节中添加<connectionStrings>节,并配置连接字符串。
b) 在webconfig<system.web>节中添加
<caching>
<cache percentagePhysicalMemoryUsedLimit="60" privateBytesPollTime="00:05:00" />
caching> (此项配置全局缓存设置,可选)
c) 建立数据访问层,如何封装编写不限,只要具有返回数据的方法即可。
d) 嵌入或者重写DaBase.cs中的protected virtual DataTable GetDataTable方法,具体请参考sqlDep示例,该方法提供自动响应程序表发生的更改,自动设定缓存机制,封装此方法后,对于开发人员,只需要按照以往开发习惯提供任意sql语句编写程序获取数据。
e) 继承DaBase类或自己编写具有protected virtual DataTable GetDataTable方法的类,并调用该方法,参见DaDimCustomer.cs。
以下我们以sqlDep做测试,以验证可行性及其性能:
我们以SqlServer2005自带的AdventureWorksDW数据库中的DimCustomer表为例,该表有29列,各种数据类型都有,18484行,7984KB数据,平均每行0.43KB。
我们以每次查询20页,查询该表的所有列作为测试。由于缓存的是查询结果,所以内存变化可以根据每次查询的数据量为基准,20行大小大约是8.6KB,缓存默认设置是允许使用服务器内存的90%,
假设对应的数据库表不做更新操作,假设Web服务器有1G的内存可使用缓存,
则可以缓存12万份不重复结果(这里没有计算.net本身每个数据实体,每个缓存相关数据所占有的空间,相对于数据而言可以忽略不计),
缓存命中率大都集中在常用查询,例如商品列表第一页,某个商品分类第一页等,一旦有某个用户使用了查询,则其他用户可以不需要访问数据库即可得到所需数据。即使缓存如果超过了程序规定的最大数据,.net运行时也会自动随即清空缓存,这并不影响程序运行。
以下附上完整代码:
WebConfig文件:
注意:对于使用本地系统帐户作为服务帐户的 SQL Server 实例,应用程序不会从其接收通知。
数据访问类:
测试页面:
PS: 如果已经注册了通知服务,可以用以下语句查询消息队列。
select * from sys.dm_qn_subscriptions
总结:
特点:特别适合更新不频繁但是读取频繁的表,会大大提高应用程序性能。
优点:缓存越多,SQL服务器负担就越小,大大减少了IO读操作以及网络传输占用。
缺点:Web服务器会稍微增加缓存调度和内存增加的负担,并且在数据库相应表发生更改后服务器会清除该表相关的所有缓存。
何时使用主动式通知机制
查询通知是针对于并不经常改变的数据而设计的。最好把它应用于服务器端的应用程序(例如ASP.NET或remoting)而不是客户端应用程序(例如Windows表单应用程序)。记住,每一个通知请求都要在SQL Server中注册。如果你拥有大量的都有通知请求的客户端应用程序,那么这可能会导致你的服务器产生资源问题。鉴于此,微软推荐,对于客户端应用程序,你应该限制使用查询通知的最大并行用户数不多于十个。
对于大规模应用程序来说,查询通知可能是一种强有力的帮助,而不用简单地添加越来越多的服务器以满足要求。设想,有一家大型的为成千上百万用户提供在线软件更新服务的软件公司。不是使每一个用户的更新操作都触发服务器上的另一个查询来确定需要哪些组件,而是能够缓冲查询结果并且可以直接从该缓存中服务匹配的查询。
对于较小规模的情况而言,下拉式列表框是另一种典型的数据集;此时该数据集更新的次数一般不如请求的次数多。产品列表、州列表、国家列表、供应商、销售人,甚至更多不太需要频繁改变的信息正是使用上述通知机制的较好候选。