它所做的就是确保用户cud操作之后，在划定的时间内还是访问主数据库，当时间超过期，才将当前用户的访问请求(select)均衡到其它从数据库中。

    
    它的作用就是加载配置文件信息，其中最重要的就是相应的‘负载均衡算法实例’来获取相应的从数据库链接串，下面先看一
下‘静态属性’GetLoadBalanceScheduling的相关信息：

       有关相应配置节点和负载均衡算法会在后面提到，这里为了坚持文章内容的持续性暂且跳过，下面接着阅读一下上面调用的‘UserSnapDatabase’方法：

      当然，在GetRealConnectionString()方法中，还有一行代码很重要，就是下面这一行：    
    

      目前在Discuz!NT这个产品中，数据库作为数据长久化工具，一定在并发访问频繁且负载压力较大的情况下成 为体系性能的‘瓶颈’。即便使用本地缓存等方式来解决频繁访问数据库的问题，但仍然会有大批的并发要求要访问动态数据，固然 SQL2005及2008以上版本中性能一直晋升，查询打算跟存储进程运行得越来越高效，但终极还是 要面临‘瓶颈’这一问 题。当然这也是很多大型网站不断研讨摸索各式各样的计划来有效下降数据访问负荷的原 因， 其中的‘读写分离’方案就是一种被普遍采取的方案。
 成都网页设计公司;     Discuz!NT这个产品在其企业版中提供了对‘读写分离’机制的支撑，使对CPU及内存耗费重大的操作(CUD)被 分离到一台或几台机能很高的机器上，而将频繁读取的操作(select)放到多少台配置较低的机器上，而后通过‘事务 发布订阅机制’，实现了在多个sqlserver数据库之间疾速高效同步数据，从而到达了将‘读写恳求’按实际负载 情况进行均衡散布的后果。
 
      下面就扼要介绍一下实在现思路。注：有关数据同步的工具已在sqlserver中自带了，可以参考这篇文章。
     
      将相应的数据由Master(主)数据库中‘发布’出来，然后使用推送的方式（注：事务发布可以指定是‘通过主 数据库推送’ 还是‘订阅服务器去获取’）发送到订阅它的数据库中，就实现了数据同步功能。
 
      下面就介绍一下如何通过改变既有代码来实当初‘几个从数据库（相似快照）’间进行读取数据的负载均衡。
 
      原有的代码中由于应用了分层机制，所以咱们只有在‘数据访问层’动一下心理就能够了。在这里我的一个设 计思路就是不转变已有的数据库访问接口（包含参数等）的条件下，实现底层主动将现有的数据拜访操作进行负载 均衡。这样做的利益不必多说了，同时也让这个负载均衡功效与数据访问层相分别，不要耦合的太严密，同时假如不知道底层 的实现原理也可以只通过一个开关（后面会先容），就可以让本人的sql语句自动实现动态负载均衡。
    
      说到这里，我来对比代码进一步论述：
 
      首先就是(Discuz.Data\DbHelper.cs)代码，主要变动如下(新增方法局部)：   

       上面的方式将会对传入的sql语句进行剖析，找出其中是CUD操作仍是SELECT操作，来差别是读还是写操作。而snapLogList列表则是之前所配置的‘事务宣布订阅’模式下的相干‘从数据库’(Slave Database)链接串的列表，例如(dbsnap.config文件的DbSnapInfoList节点)： 

      该办法的作用很简略，就是当数据库有CUD操作时，通过写cookie的方法向客户端写一个键值‘JumpAfterWrite’，这个键值很主要，就是供给一个标签(flag)来唆使：‘当前用户履行cud操作时，页面跳转到其它页面而主数据库还没来得及将数据推送到从数据库’这一情形而造成的‘数据不同步’问题。
     举了例子，当在一个版块中‘发表主题’后系统自动跳转到‘显示该主题页面’时，如果主数据库中插入了一个新主题而从数据库不被及时更新这一主题信息时，就会报‘主题不存在’这个过错。所以这里加了一个设置，就是下面这一行：