博客园_.NET

视图后面加with(nolock)后

2012-02-09T02:12:00Z

      一些小的企业项目，往往存在很多局限性，这里讲的局限性是指这些项目在面对某些需求时，所选用的解决方案不多。就拿我目前处理这个来讲吧，说的通俗点就是为业务部门生成相关报表。我目前理解的报表生成方式，总结如下：

      第一：在业务库上执行SQL语句或者存储过程，实时生成数据。这其中又分为三种：

       1：在主库上操作，及业务系统操作的数据库与生成报表的SQL逻辑同处一个数据库。
       2: 在主库的只读库即从库上操作，一般可以通过订阅复制来设置主从库，产生报表的逻辑只操作从库。
       3: 主库定时生成一个备份库，报表从生成的备份库中操作。

      第二：由数据仓库生成相应报表。
          这部分在这里就不多说了。

      我目前的项目就属于第一种的第一小分类，即直接在主库上以执行SQL方式产生数据，其中的原因也不用多说，低成本。但由于生成报表的需要的时间一般都较长，容易对业务表进行长时间的锁定，影响业务系统的正常使用，反过来，如果用户正在操作业务库，此时如果同时执行报表生成，就会形成锁等待。为此决定对报表相关查询表进行无锁操作，即在表后面加 with(nolock)，但我们为客户端是以视图形式提供，为此产生一个问题：在视图后面加with(nolock),是否意味着视图内的所有表都是nolock?

      我在网上没找到相关内容，于是还是眼见为实，决定做个小实验。重点需要搞清楚如下几个问题：

      问题一：如何人为造成一个锁？即让某个表被某个线程长时间锁定。

我们可以BEGIN TRAN mytran，然后操作一个表，比如update，但不commit tran,此时被操作的表就会被当前线程长时间锁定。我们可以用sp_who2来查询锁定情况，如下图所示，第一个框代表状态，第二个框是CPUTime。还可以利用sp_lock查看锁的类型。

      问题二：如何制造脏读的情况，我们都说加了nolock，容易形成脏读，但脏读到底怎么样呢？

      1:创建一个测试用的表：

--创建表
CREATE TABLE mytest
    (
      id INT IDENTITY
             NOT NULL ,
      data UNIQUEIDENTIFIER DEFAULT ( NEWID() )
                            NOT NULL
    )

这里需要创建一个聚焦索引，如果不创建此聚焦索引，后续的结果会发生变化。

--创建索引
CREATE UNIQUE CLUSTERED INDEX cidx ON mytest( data )

2：为表添加一些测试数据。

--添加数据
DECLARE @i INT ;
SET @i = 1 ;
WHILE @i <= 50000
    BEGIN
        INSERT  mytest
                DEFAULT VALUES
        SET @i = @i + 1
    END

3:创建测试视图：

CREATE VIEW view_mytest
AS
SELECT * FROM mytest
go

4：创建一个嵌套视图，嵌套视图的目的就是想看看在最上层视图上加nolock，是否会传递到最底层的基表。

CREATE VIEW view_mytest2
AS
  SELECT a.* FROM view_mytest a
  LEFT JOIN dbo.Report b
  ON a.id=b.id
go

     5：在MSMS中打开两个窗口：
      窗口一：执行如下脚本，提交一个事务，更新测试表，但不提交，形成长时间锁定。

BEGIN TRAN mytran
UPDATE mytest
SET data = NEWID()

窗口二:对测试表进行行数统计，当发现数据出现错误时，打印出提示信息。

DECLARE @totalrows INT ,
    @currentnow INT ,
    @errorcount TINYINT
SET @errorcount = 0
SELECT  @totalrows = COUNT(1)
FROM    mytest
WHILE 1 = 1
    BEGIN
        SELECT  @currentnow = COUNT(1)
        FROM    view_mytest2 WITH ( NOLOCK )
        IF @totalrows <> @currentnow
            BEGIN
                PRINT '查询总数= ' + CAST(@currentnow AS VARCHAR(10)) + ' 差异数量= '
                    + CAST(@currentnow - @totalrows AS VARCHAR(10))
                SET @errorcount = @errorcount + 1
                IF @errorcount >= 8
                    BREAK
            END
    END

6：查看窗口二，如果nolock,理论上应该会出现错误提示信息，出现此错误提示信息就是因为在无锁情况下有可能出现多读或者是少读的现象。

上图表示，在视图上添加nolock跟在基表后加nolock效果一样，只不过在视图上加就相当于视图内所有表都无锁，这样不太灵活，尽管有脏读现象，但我们的业务逻辑一般都是多表相匹配后的情况，如果一个事务中会操作多个表，生成报表时，某些表形成了脏读，也不会影响最终数据，如果所有表都操作完毕，还未提交事务，此时虽然查询出的数据可能是错误数据，但属于可接受范围之内。

文中若不错误地方望批评指正。

参考资料：http://www.dotblogs.com.tw/ricochen/archive/2011/04/15/22758.aspx

本文链接

如何分离web.config改进版本

2012-01-13T13:16:00Z

      三年前我分享了如何分离web.config中的配置节,因为有些项目过大，造成N多配置节存在于web.config中，缺点如下：
      1:不容易管理，当你想查找一个配置节时，望着整页的code，不知所措，为此你只有ctrl+f来解决。
      2:部署时也及容易出错,部署人员需要按照你写的部署文档，一个一个加,即费时又容易出错，比如一不小心将其它节点给覆盖了诸如此类。
      3:在web.config中的配置节的修改会引起站点重启。
      4:访问配置节不够简单，容易出错。

文章之前我提到过我们为了解决此种问题的解决方案，就是将配置节从web.config文件中分离出来，将配置节存入单独的文件中。具体的方案请参考前面的文章(如何分割web.config )，有很长一段时间没有使用了，最近在使用上发现在多项目中复用有一定问题，即每个项目都需要编写一段不短的代码，下面就是我对于它的优化过程，先看下原来的工作量：

第一：Webconfig，这是框架里面的内容，这也是唯一得以复用的地方。它是一个入口，所有的配置文件引用都通过它，比如访问酒店的配置类，WebConfig.Hotel.HotelName。代码如下：

public partial  class WebConfig
    {
        /// <summary>
        /// 启动配置类
        /// </summary>
       public static void OnStart(string configFilePath, FileUpdate fileUpdate)
        {
            #region  实现配置文件独立
            //第一次启动需要执行委托方法更新配置类
            fileUpdate(configFilePath);
            //启动文件监视
            Log4netFileWatchHelper.StartWatching(fileUpdate, configFilePath);
            #endregion
        }
        /// <summary>
        /// Config/Web 文件夹的磁盘路径
        /// </summary>
       public static string ConfigFilePathRoot
       {
           get;
           set;
       }
    }

1:包含一个重要方法OnStart,可以对配置文件进行初始化，其实这个初始化也可以省略掉，因为完全可以将初始化配置类变成延迟加载模式。
2:一个配置文件路径的属性，它标识了此项目类所有配置文件的存放目录，可以在程序初始化时指定此属性。

第二：自定义的配置文件类，比如我们可以添加一个数据访问的配置类。

[Serializable ]
    public  class DataAccessConfig
    {
        #region 需要序列化的配置文件属性
        /// <summary>
        /// 数据库信息列表
        /// </summary>
        public List<DataBase> DataBaseList { get; set; }
        #endregion

        #region 相对于Config文件夹的子文件路径,不需要序列化.
        /// <summary>
        /// 相对于Config文件夹的子文件路径,不需要序列化.
        /// </summary>
        [NonSerialized()]
        private static string m_SubFilePath = @"DataAccessConfig.config";
        /// <summary>
        /// 子文件路径(排除config文件夹路径后的部分)
        /// </summary>
        public static string SubFilePath
        {
            get { return m_SubFilePath; }
            set { m_SubFilePath = value; }
        }
        #endregion
        public static DataAccessConfig CreateInstance()
        {
            FileUpdate fileUpdate = new FileUpdate(WebConfig.DataAccessConfigOnUpdate);
            string configFilePath = WebConfig.ConfigFilePathRoot + DataAccessConfig.SubFilePath;
            if (!File.Exists(configFilePath))
            {
                return null;
            }
            DataAccessConfig config = SerializationHelper.Load(typeof(DataAccessConfig), configFilePath) as DataAccessConfig;
            //启动文件监视
            Log4netFileWatchHelper.StartWatching(fileUpdate, configFilePath);
            return config;
        }
    }

    public partial class WebConfig
    {
        #region 第二步:为DataAccessConfig类添加入口
        /// <summary>
        /// 属性对应的私有变量
        /// </summary>
        private static DataAccessConfig m_DataAccessConfig = null;
        /// <summary>
        /// 属性访问器.通过WebConfig.SimpleFileDemoConfig可以访问此类.
        /// </summary>
        public static DataAccessConfig DataAccessConfig
        {
            get
            {
                if (m_DataAccessConfig == null)
                    Interlocked.CompareExchange<DataAccessConfig>(ref m_DataAccessConfig,
                        DataAccessConfig.CreateInstance(), null);
                return m_DataAccessConfig;
            }
        }
        #endregion

        #region 第三步:为DataAccessConfig类添加更新函数
        /// <summary>
        /// 更新函数
        /// </summary>
        /// <param name="status"></param>
        public static void DataAccessConfigOnUpdate(object status)
        {
            lock (WebConfig.DataAccessConfig)
            {
                try
                {
                    m_DataAccessConfig = DataAccessConfig.CreateInstance();
                }
                catch (Exception ex)
                {
                    throw ex;
                }
            }
        }
        #endregion
    }

       这段代码就是我们要实现的部分，不能复用，总觉的需要改进一下，问题分析：
       1：由于需要采用静态调用方式，为此要想通过WebConfig的静态属性调用，就需要在WebConfig类中增加自定义配置类的属性，比如我们增加一个Hotel相关的配置类，而要想WebConfig.Hotel，就需要增加一个静态属性方式实现。这里可以稍微修改下，即最后在配置自定义配置类时只编写自定义配置类，而不用去编写WebConfig类。
       2：自定义配置类中的CreateInstance，也要考虑复用。

       原则就是自定义的配置类不关心如何读取配置文件，只关心自己的配置属性即可。

       改善后的版本：
       1:针对WebConfig.自定义类方式。这里我修改的方法也不是最好的，用起来没有修改前的顺畅，但代码确实精简了。思路就是在WebConfig类中生成一个泛型配置类。

public partial class WebConfig<T> :WebConfig where T:class

这里新增了WebConfig的泛型版本，而将WebConfig提取成基类，WebConfig类中包含一个属性，即配置文件所在文件夹路径。

/// <summary>
        /// Config/Web 文件夹的磁盘路径
        /// </summary>
        public static string ConfigFilePathRoot
        {
            get;
            set;
        }

WebConfig<T>主要目的是为了生成T类型的配置类,这里将原本在自定义配置类中的代码提取到WebConfig<T>中：

         /// <summary>
        /// 属性对应的私有变量
        /// </summary>
        private static T m_DataAccessConfig ;
        /// <summary>
        /// 属性访问器.通过WebConfig.SimpleFileDemoConfig可以访问此类.
        /// </summary>
        public static T DataAccessConfig
        {
            get
            {
                if (m_DataAccessConfig == null)
                    Interlocked.CompareExchange<T>(ref m_DataAccessConfig,
                        CreateInstance(), null );
                return m_DataAccessConfig;
            }
        }
         /// <summary>
        /// 更新函数
        /// </summary>
        /// <param name="status"></param>
        public static void DataAccessConfigOnUpdate(object status)
        {
            lock (WebConfig<T>.DataAccessConfig)
            {
                try
                {
                    m_DataAccessConfig = CreateInstance();
                }
                catch (Exception ex)
                {
                    throw ex;
                }
            }
        }

        2:将自定义配置类生成实例的方法也进行封装。

private static T CreateInstance()
        {
            SubFilePath = typeof(T).Name+".config";
            string configFilePath = WebConfig<T>.ConfigFilePathRoot + SubFilePath;
            if (!File.Exists(configFilePath))
            {
                return null;
            }
            T config = SerializationHelper.Load(typeof(T), configFilePath) as T;
            //启动文件监视
            FileWatch(configFilePath);
            return config;

        }

        有了上面的提取封装，下面就是改版后的自定义类了,到目前为止，我们编写一个自定义配置类的成本已经非常低了：

[Serializable]
    public class MyConfig : WebConfig<DataAccessConfig>
    {
        #region 需要序列化的配置文件属性
        public string ExpenseTemplateFile { get; set; }
        public bool Switch { get; set; }
        #endregion
    }

最后我们添加一个配置文件，名称和自定义配置类保持一致。

  <?xml version="1.0" encoding="utf-8" ?>
<MyConfig>
  <ExpenseTemplateFile>ssssss3</ExpenseTemplateFile>
  <Switch>false</Switch>
</MyConfig>

客户端调用方式：

WebConfig<MyConfig>.DataAccessConfig.Switch

虽然本次改版并不完美，但在多个项目中利用时还是起到了很大的作用，编写简单，调用方便，唯一不满意的就是需要这样写：WebConfig<MyConfig>，没有以前的WebConfig.MyConfig方式来的舒服。

本文链接

终于尝试了一次EF

2011-12-13T08:10:00Z

    其实我对微软出的Linq to Sql，以及Linq to Entity这两个产品兴趣都不大，不太喜欢那种开发模式，主要原因如下：
    1:自动生成的那堆代码，不利于平时的分层模式，将实体以及存储逻辑混合在一起总觉的不是那么回事；
    2:对于编写测试用例不是那么友好，全部逻辑都在一起，无法拆分测试，比如只想测试代码逻辑，不需要连接真正的数据库等。
    3:在排除程序BUG时，还是习惯于看直观的SQL，这样在数据库中调试起来更加容易些，可能是个人习惯问题；
    4:据说性能上存在一定缺陷，本人并未测试过，道听途说而已。

    之所以这次想尝试一次，主要基于两点：首先我现在接手的一个项目是用EF编写的，其次就是EF 4.2能够将原来混合在一起的代码给分离开,说的官方点，这个分离功能叫POCO，英文全名是Plain Old CLR Object，翻译成中文是简单传统的CLR对象。总之最新的EF允许开发人员手工编写更多代码，不再一味的依赖代码自动生成。

    第一：如何安装EF 4.2？

    我电脑上原来安装的是EF 4.0，这次选择的是通过NuGet方式安装。
    1:首先从VS菜单上选择工具，然后选择扩展管理，如下图。

2:在弹出框的左侧选择Online,然后在右上角搜索Nuget,最后进行安装。

3:安装NUGET后，我们在工程的引用中点击右键，就会多出一项来，如下所示。

4:添加EF引用。点击上图中的最后一项，搜索EntityFramework，就会看到最新的EF了，选择进行添加即可。

第二：创建EF程序。

我采用的是最早的模式，即先有数据库，然后再有程序的模式，程序分了如下几层：

1:ModelFirstSample.DAL,这是数据层，用于存放与数据库打交道的逻辑；
先按正常流程添加一个ADO.NET Entity Data Model,按步就班，一步一步下来就行。这样会生成一个.edmx的文件。

然后打开edmx文件，点击右键选择添加代码生成项，在弹出的菜单中选择Db context那项，接下来会生成PersonModel.tt，PersonModel.Context.tt两文件，对应的edmx下面的自动生成的代码已经为空了。

    2:ModelFirstSample.Model,实体层，将EF生成的.edmx,.tt文件放在这，与存储逻辑分离；
      将第一步生成的PersonModel.edmx,PersonModel.tt添加到工程下面，同时删除原文件，这样就实现了实体层与存储逻辑的分离。
    3:ModelFirstSample.BLL,业务逻辑层，不用多说；
    4:ModelFirstSample.Service,服务层，对于业务逻辑层的进一步包装；
    5:ModelFirstSample.ConsoleApp,UI层。

    第三：EF中的开发模式之Repository。

在实际项目中，如果希望能够对存储逻辑有一定的控制，于是就有了repository模式的出现,也就是对原始存储逻辑的一种封装。
1:在接口层中创建一个通用的存储接口IRepository<T>,便于逻辑复用。

public interface IRepository<T> where T : class, new()
    {
        T Create();
        T Update(T entity);
        T Insert(T entity);
        void Delete(T entity);
        T Find(params object[] keyValues);
        List<T> FindAll();
    }

2:在DAL层中创建一个实现了IRepository<T>接口的RepositoryBase<T>基类，主要的就是需要提供一个DbContext,基本思想就是利用DbContext的Set<T>构造的类型来提供封装,这里就不做多的说明了,我这里为了简单，使用了默认构造方法，FacePerfEntities是添加edmx时生成的类。

public class RepositoryBase<T> : IRepository<T> where T : class,new()
    {
        public DbContext context;

        public RepositoryBase(DbContext _context)
        {
            this.context = _context;
        }
        public RepositoryBase()
        {
            this.context = new FacePerfEntities();
        }
        #region IRepository<T> 成员

        public T Create()
        {
            return context.Set<T>().Create();
        }

        public T Update(T entity)
        {
            if (context.Entry<T>(entity).State == EntityState.Modified)
                context.SaveChanges();
            return entity;
        }

        public T Insert(T entity)
        {
            context.Set<T>().Add(entity);
            context.SaveChanges();
            return entity;
        }

        public void Delete(T entity)
        {
            context.Set<T>().Remove(entity);
            context.SaveChanges();
        }

        public T Find(params object[] keyValues)
        {
            return context.Set<T>().Find(keyValues);
        }

        public List<T> FindAll()
        {
            return context.Set<T>().ToList();
        }

        #endregion
    }

3:在接口层中创建一个关于员工的接口：IEmployeeRepository<T>

public  interface IEmployeeRepository<T>
    {
       List<T> SearchEmployee();

    }

4:在业务逻辑层中创建关于员工的专用类：EmployeeRepositoryBLL。

public class EmployeeRepositoryBLL : IEmployeeRepository<Employee>
    {
        EmployeeRepository repository = new EmployeeRepository();
        public List<Employee> SearchEmployee()
        {
            return repository.FindAll();
        }

    }

5:在服务层中创建员工的服务类，由于这只是测试用，所以服务类起的作用并不明显，至于为什么有服务层，是为了将UI层与业务逻辑层分离等等众多原因。

public  class EmployeeRepositoryService
    {
       EmployeeRepositoryBLL repositoryEmployee=null  ;
       public EmployeeRepositoryService()
       {
          repositoryEmployee = new EmployeeRepositoryBLL();
       }
       public List<Employee> SearchEmployee()
       {
          return this.repositoryEmployee.SearchEmployee();

       }
    }

6:最后就是UI了。

static void Main(string[] args)
        {
            EmployeeRepositoryService ers = new EmployeeRepositoryService();
            var list = ers.SearchEmployee();
            var people = from p in list
                         orderby p.CreatedOn
                         select p;

            Console.WriteLine("All People:");
            foreach (var person in people)
            {
                Console.WriteLine("- {0}", person.ChineseName);
            }
            Console.WriteLine("Press any key to exit...");
            Console.ReadKey();
        }

     补充说明：

     1:添加完edmx后，以及完成添加代码生成项后，查询PersonModel.Context.cs，代码如下:

public FacePerfEntities()
            : base("name=FacePerfEntities")
        {
        }

       构造函数中的参数FacePerfEntities,其实就对应EF数据库连接串的节点名称。

     2:添加完edmx后，在DAL层还会有一个packages.config文件，这个文件不用发布到UI程序下面，也不影响程序运行，只需要将连接串对应的节点复制到UI配置文件中即可。

   总结： 经过上面的改造，已经越来越适合实际项目了，EF在不断改进，我想在一些小型项目中快速开发倒是蛮适合的。

注：本文参考

http://blogs.msdn.com/b/adonet/archive/2011/09/28/ef-4-2-model-amp-database-first-walkthrough.aspx

http://www.cnblogs.com/mecity/archive/2011/07/07/2099598.html

http://www.cnblogs.com/chsword/archive/2011/09/14/NuGet_Install_OperatePackage.html

本文链接

我对架构的理解－概念篇

2011-10-16T02:37:00Z

     这两天和一朋友讨论这样一个问题：你认为公司的架构怎样，有哪些缺点？

     其实在回答这个问题之前，有一些概念需要搞清楚，那就是什么是架构？

     目前对于架构还并未有一个统一的标准及定义，所以架构的概念就会因为每个人不同而不同，如果尝试问一百人关于架构的理解，可能有一百个答案。

     我开始做基础架构到现在已经有两年时间了，但对架构的理解也并不深，有时感觉无从说起，总觉的是一个无形的东西。下面我就总结下我个人对架构的理解，下面纯属个人理解。

     第一：架构分层，这里我将架构分为以下两层：

          1：基础架构，这也是由于架构本身的一大特点，具备基础性，它的基础性可以这样理解：通常涉及解决各种关键问题的通用方案，即重用性概念，以及涉及系统设计中影响深远的各种方案决策，影响深远说明一旦确定再次修改的代码往往过大。

          示例1：各种中间件，中间件就是对某些组件的一种包装，比如我们的系统在访问数据库是需要同时支持多种类型的数据库，比如SQL SERVER,MYSQL ,ORCAL，等等，为了在各种系统访问数据时形成统一的管理，我们可以编写一个通用化的组件来解决此种问题，达到管理容易，编写简单的目的。
          示例2：各种通用服务，例如为所有项目提供分布式缓存系统，所有的项目数据都可以通过它来完成数据的缓存，以加强系统性能。
          示例3：面向服务概念SOA的实现，通过SOA可以使复杂的业务系统得到解耦。
          示例4：项目的分层，比如分几层，每层的功能，想到之间的关系等。

          2：对于全局的组织，全局的结构控制，为特定需求提供特殊解决方案，这类重在设计思维。

          示例1：如何将复杂系统化分成N个子系统；
          示例2：如何实现系统的非功能性需求，比如并发性，稳定性，可扩展性等等；
          示例3：设计方案的选择，评估等。

下面是我对于架构的分层结构图：

     第二：架构所关心的问题有哪些,通过这些问题，就会发现架构的概念是如此之大，并非三言两语就能说明白的。

          1：全局组织和全局结构
          2：数据存取协议
          3：各种组件的功能定义
          4：软件的物理部署
          5：设计方案的选择
          6：架构评估与实现

     第三：架构都有哪些重要作用

         1：它是项目干系人进行交流的手段。它代表了系统公共的最高层次抽象，系统相关的很大部分人员均可将它作为互相理解的基础，以此达成共识；
         2：上面说到架构具备基础性，所以具备可传递性与可重性的特点，架构层次上的重用性与代码级的重用性有本质区别，它意味着架构的决策能在相似的需求中出现在多个系统中,体现在决策，而不是实现细节；
         3：它是早期设计决策的体现，这些决策比以后的开发，设计以及编码以后期的维护工作重要的多。

     第四：需要注意的几个观点，为了更加正确的认识架构，需要正确对待类似下面的观点

         1：框架(Framework)，框架在一定程度上容易让人理解为架构，其实框架只是架构内容中的一种，代码级别的组件，不能认为搞搞框架就是架构的全部了。比如我们写的各种是间件，为某种特定需求开发的某种具备特殊功能的组件。

2：写大量的中间件是架构吗？是，但它也只属于架构的一小部分，说的准确点是框架的一部分；

3:SOA算架构吗，当然算，它就是上面我理解的基础架构一部分，但这些均只是架构的冰山一角;

         4:某公司成功的架构模式能直接移置到另外一家公司的项目中吗？这个问题不能武断，我认为如果项目类型大致相同，移置的可能性会比较大，否则就需要慎重，比如我们不能将一个C/S架构上的思想直接移到到B/S架构的项目上，它们之间的差距是非常大的,即使勉强移置，也需要非常明确以后需要改进的地方，比如说性能问题，原来的架构所应用的环境对性能要求不高，所以运行良好，但如果不变的移置到互联网项目了，郁闷的事就会出来了。

      第五：如何表示软件架构,可以通过非常经典的4+1视图模型来从5个不同的视角来反映系统的整体架构：
           1：逻辑视图，主要体现的是系统需求，在逻辑视图中，系统会被抽象成一堆的功能抽象，这些抽象主要是来自需求。功能分解有两个功能，第一：进行功能分析；第二：可以提取不同功能模块中可重用点。
           2：进程视图，它主要体现系统中的一些非功能性需求，侧重于系统运行时的特征，例如：系统的性能，稳定性，申缩性，并发性，容错能力，分布式等等。
           3：物理视图，它主要考虑的是系统的部署问题，比如部署在什么样的硬件上，解决系统的拓扑结构，通信等问题，比如数据库的备份容灾方案等。
           4:开发视图，主要解决系统的组织以及管理，比如如何划分子系统，如何编写要重用性组件等。
           5:场景视图，它联系以上四个视图，是系统活动的重要抽象，它用来解决在特定场景上分析一个特定的视图。

           下面是它们的关系图

总结：架构是一个大概念，不会有统一的定义，每个公司每个项目都会对架构产生影响，只有根据实际情况出发，才有可能开发出最适合自己公司项目的架构模式。

本文链接

通过问题学习asp.net mvc局部处理流程

2011-10-09T08:43:00Z

    本人平时比较喜欢和他人讨论一些技术上的问题，并不是我技术有多么好，而是我喜欢在这种讨论中从中获取新知识，同时也可以将自己的心得与他人分享，最近一朋友的问题如下：

    问题：asp.net mvc是如何处理请求的，即当用户在浏览器中输入URL后，是怎么一步一步处理，最终找到对应的Controller,然后执行相对的Action？

    用了mvc有小两年了，但目前也只陷于会使用它，对它里面的好多原理我并没有深入的进行研究，尽管我知道一些请求处理流程，但在针对MVC时，有些细节一时没想起来。http请求从头来讲有点多，这篇呢我只想从http请求进入了appDomain开始,其它部分以后再总结。下面是我当时的回答：

    第一：有一个HttpApplication的东东。
          注：至于它是做什么的，我当时也没多说，也没印象了。
          缺点：直接就从它开始，显然是错误的：
          1：在这之前应该有一个非常重要的类：HttpRuntime,没有它怎么生成HtppContext?
          2:在HttpApplication之前，还有一个工厂类，HttpApplicationFactory。

    第二：过了HttpApplication后就是一堆的HttpModule。

          缺点：显然没有结合MVC，应该说一个和MVC相关的Module才行吧。

    第三：最后就是真命天子HttpHandler,由它负责处理后续过程。

          缺点：
          1:和上面一样，没有提到任何和MVC相关的东西，起码对于重要的处理路由的MvcRouteHandler没有说,说大概念MvcHttpHandler也行呀；
          2:之前我以为Controller继承了IHttpHandle,就像asp.net webform中的Page继承了IHttpHandler一样,后来仔细找了找，发现没有，两者在处理流程上是有区别的。

    上面的回答显然不专业，从回答中看不出MVC的路由原理，为此我画了如下一张图，稍微清楚些：

    通过这张图我们可以更加详细的了解到它们各自的作用：
    1：HttpRuntime:这有一个重要方法ProcessRequest,这个方法里面有一个参数HttpWorkerRequest，里面包含了所有http信息，至于HttpWorkerRequest是怎么来的，以后找时间总结下。最后它将请求交给HttpApplication；
    2:HttpApplicationFactory:这个没什么好说的，它的作用就是创建一个HttpApplication;
    3:HttpApplication:它代表我们的web应用程序，程序中的Global就继承于它；
    4:HttpModule:它可以决定请求最终由哪个具体的IHttpHandler来处理，同时可以在进入IHttpHandler之前可以对HttpContext做些处理，比如增加一些附加信息等等；
    5:HttpHandler:它是最终负责处理请求的类，比如MVC中的MvcRouteHandler

    其实上面的这些局部知识，比如我们从哪知道UrlRoutingModule，MvcRouteHandler等？答案都可以从我们创建的asp.net mvc项目中找到。

    我们看看生成的Web.Config文件，再查下资料就能找到答案了，从配置文件中可以清楚看出MVC路由依赖什么,知道了这些，当你看到MVC项目生成config后，再比较asp.net webform的配置文件，就会明白为什么有那些差异了。

    总结：这篇文章就是为了在知道怎么做的情况了，也能知道为什么能这么做。

    注：如文中有误解之处，希望批评指正。

本文链接

总结WCF开发中遇到的几个问题

2011-09-15T02:15:00Z

      最近的项目，需要用到WCF，在以前的工作中，经常是将WCF托管在IIS中，主要有几下几个原因:
      第一：部署非常方便，和部署一个站点没什么区别；
      第二：不受防火墙的影响，因为一般服务器上80端口都是开放的；
      第三：IIS托管不需要程序编写托管代码。

      以前WCF的绑定基本上都是用wsHttpBinding，但这次项目需要将WCF配置成MSMQ，于是我们就需要用到netMsmqBinding,在采用netMsmqBinding过程中遇到如下问题：

      第一：netMsmqBinding绑定权限问题。
      原来服务托管在控制台时，服务正常，但托管在windows服务时就会出现如下异常：
      System.TypeInitializationException: “System.ServiceModel.Channels.Msmq”的类型初始值设定项引发异常。 ---> System.ServiceModel.MsmqException: 版本检查失败，错误为:“消息队列服务不可用 (-1072824309, 0xc00e000b)”。无法检测到 MSMQ 的版本。该队列通道上的所有操作都将失败。确保已安装 MSMQ 且 MSMQ 可用。
      这条信息显示没有权限，但控制台是没问题的，原因如下：
      创建消息队列是用登录帐户，而运行控制台程序也是登录帐户，所以没有权限问题，但windows服务在运行时的帐户不一定就是登录帐户，一般我们指定的是ServiceAccount.LocalSystem,于是将消息队列增加everyone权限，问题解决。

      另外我将服务托管在IIS7上，总会不成功，不知道大家有没有成功过，如果有成功的，希望给个示例。队列权限为everyone,还加了个匿名用户。

      第二：服务端与客户端配置不同导致不能通信，当采用默认生成的配置通信正常，采用程序编码形式编写配置，通信异常，最后发现是binding中的属性exactlyOnce值不同。这种配置主要是指服务端的配置，比如客户端的超时时间等设置就可以任意指定。

NetMsmqBinding result = new NetMsmqBinding(NetMsmqSecurityMode.None);
result.ExactlyOnce = false;

      第三：服务托管方式问题。
      由于本人还未将netMsmqBinding托管在IIS上，所以只能托管在windows服务中，本来托管在控制台也可以，但应用程序的开启比较容易受其它登录用户的影响。这托管成windows服务时遇到如下问题：
      场景：我需要将同一服务程序，部署为N个不同端口不同服务名称的服务。
      问题：当安装一个服务后，正常启动，在安装第二个服务时，第二个服务的执行地址会记成第一个服务的地址。
      分析：有可能是windows服务在安装过程中有安装记录，即使指定了服务程序路径也会受影响,大家有啥好办法就请教。
      解决方案：将服务的exe,config更改名称，例如ComputeAsyncTask_Hight_1.exe，ComputeAsyncTask_Hight_2.exe，ComputeAsyncTask_Hight_3.exe，这种情况下，安装后的执行路径就没有问题。
      遗留问题：虽然上面方案能解决执行路径问题，但在如下情况下依然有问题：
      当所有服务都正常安装后，再次执行安装，比如再次安装ComputeAsyncTask_Hight_1.exe,首先是服务删除，此时系统所识别的assemblypath依然是ComputeAsyncTask_Hight_3.exe,此时就会将ComputeAsyncTask_Hight_3删除，这种情况目前还未找到好的方法。

      第四：如何快速彻底删除一个windows服务
      当一个服务安装后，但由于某些BUG做了调整，在某种情况下就会出现无法删除服务的情况，这种问题经常消耗我大量时间去排查，我们可以借用用sc.exe这个Windows命令来解决，效果非常好，再也不用花精力去分析服务为什么不能删除的原因了。
        开始——运行——cmd.exe，使用办法很简单：
        sc delete "服务名" (如果服务名中间有空格，就需要前后加引号）

      第五：在服务的安装类中不能引用app.config
      如果将服务托管为windows服务，一般都会编写服务安装代码，这样我们就可以利用ManagedInstallerClass.InstallHelper来实现服务的自动安装，它主要是用来代替Installutil.exe手工操作。我在项目中需要将同一服务程序部署为不同端口不同服务名称的服务，所以我考虑将服务名称从app.config中指定，于是就是类似下面的代码：

service = new ServiceInstaller();
service.ServiceName = ConfigurationManager.AppSettings["ServiceName"].Trim();

      但在安装过程中总是报错，查明原因，是无法找到配置节，最后才知道当服务在安装时，并不是一个应用程序，理所当然就不会加载app.config,所以在安装类中我们不能调用app.config。
      解决方案：将配置节从app.config中转移，比如新建一个xml文件，然后在安装时，服务名称等信息从xml配置文件中读取。

      service.ServiceName = GetComputeLevel();
      private string  GetComputeLevel()
        {
            try
            {
                string strPath;
                XmlDocument xmldoc = new XmlDocument();
                XmlNode xmlnd;

                strPath = System.Environment.CurrentDirectory + @"\ComputeLevelConfig.xml";
                strPath = AppDomain.CurrentDomain.BaseDirectory + @"\ComputeLevelConfig.xml";
                if (!File.Exists(strPath))
                {
                    throw new FileNotFoundException("未能找到配置文件"+strPath);
                }
                xmldoc.Load(strPath);
                xmlnd = xmldoc.SelectSingleNode("ComputeLevelConfig");
                if (null != xmlnd)
                {
                    return xmlnd.InnerText.Trim ();
                }
                else
                {
                    throw new Exception("没有指定计算优先级!" + strPath);
                }
            }
            catch (Exception ex)
            {
                throw ex;
            }
        }

   第六：重新认识WCF服务端配置。
        以前在开发WCF时，大多都是基于默认配置，当一个服务写好之后，以后在开发新的服务，基本都是参考以前成功的案例，所以对服务端的配置文件未做过多了解。借这次机会，重新整理下服务端配置文件的构造情况。
        主体结构分为以下三个部分：
        1:behaviors
          默认情况会出现如下两个节点，如果想让服务端向客户端抛出详细错误，可以修改includeExceptionDetailInFaults,其它的节点我目前还未使用过。

        2:bindings
         指定绑定模式，我这里指定netMsmqBinding，下面的内容，可以补充一些与默认值不相同的内容，比如exactlyOnce,security，其它不需要额外指定的，就为默认值。

        3:services
          最重要的数endpoint以及host,endpoint理解ABC就行：
          A:address,服务地址，如果是wshttpbing这种IIS托管形式，此处应该为空字符串，如果是非http绑定，例如netMsmqBinding,需要指定队列地址；
          B:binding，绑定类型
          C:contract，服务契约
          host这个结点一般是针对非http绑定，用它来提供基地址,http绑定就不需要配置了。

理解它的结构，以后在配置各种类型的服务时就能心中有数了。

本文链接

异步计算架构解决准实时数据处理

2011-08-27T13:11:00Z

    之前的文章中我有谈到过我们有一个需求：对一些数据需要准实时效果，但这些数据往往是不能通过直接查询业务数据来反映的，大多都需要经过一系列复杂的运算才能体现出来,于时这些数据的实效性就是一个很大的问题。

    我们一个业务数据点的触发，实际上会影响到多个数据指标的变化，每个指标数据都是一个具体的业务逻辑，如果将这众多的指标放进一个事务中执行显的不太可能，第一是执行时间，第二是随着处理过程过程的复杂，事务提交失败的可能性会增大。如果将每个点当成原子操作，那么如何保证最终的数据是完整准确，就是问题所在，即一个业务数据触发后，不允许出现一部分统计数据准确，有一小部分不准确的现象。

    解决众多原子操作数据完整性的一个方案是将每个原子操作的处理过程全程记录下来，如果发现最后处理完成后，有没有成功的，将用程序的方式回滚之前已经成功修改的数据。这种方案有两个缺点：
    第一：回滚逻辑比较复杂；
    第二：如果计算服务发现不可用，此时业务系统的数据将不能触发数据计算，最后导致这些数据无法参与计算。

    解决方案：将业务系统数据发送给MSMQ，WCF封装成MSMQ形式，它会监听MSMQ，如果有消息收到就会处理。和原方案一样，将每个原子数据操作的结果记录下来，如果最终发现有一个失败，就会将此消息发送给异常消息队列，再由专门的服务对这些有计算失败的消息进行处理，异常处理服务根据消息处理日志就能够区分出哪些是需要重新计算的，因为有一些数据是已经计算成功过的，这样可以避免重复计算。同样由于MSMQ可选用磁盘化的存储，所以即使计算服务当时不在线，这些消息也会在服务正常启动后再次发送,避免数据丢失。

    异步计算框架的结构：

    1：异步计算代理，它负责接收业务系统提交的数据，然后提取任务配置信息，最后通过软负载方式，将消息发送给不同级别的计算服务进行运算。
    2：一组计算服务，它们根据优先级分成高，中，低等等，高优先级的服务数量最多，比如是这样的方式高3，中2，低1。如果有100个请求，高优先级来运算，每个服务只需要处理不到40个讲求，如果中优先级来处理，每服务需要处理50个，最差的低优先级需要处理100次。
    3：异常计算服务，处理前面的计算服务中，有计算出现错误的消息，如果此时再次失败，将消息进行持久化，供人工解决。
    4：持久化存储，这里采用mongodb，我们在进行大量日记记载时能够获得最大的性能优势。

    异步计算框架的数据流向图：

本文链接

Mongodb官方驱动的进一步包装

2011-08-27T00:32:00Z

    最近有一个需求，对数据的实时性要求比较高，之前寻找过一些内存数据库，首先将收费的产品先排除掉，然后再排除一些嵌入式产品，最终留下两个产品：
    1：Mysql内存引擎;
    2：基于内存文件映射的文档数据库Mongodb;

    针对以上两种产品，mysql内存引擎有如下缺点是我们放弃的理由：
    1：数据量比较大的情况，比之innodb引擎优势并不明显，数据小的时候采用B-Tree索引结构性能还是可以接受的。
    2：内存引擎对于持久化是非常吃力的，如果大量数据操作均在内存引擎中完成，那么就需要我们来做数据的持久化，无论是复制订阅方式还是程序方式均存在比较大的困难。

3:内存引擎所占用的数据空间比较大，特别是默认的hash结构，同数据量的数据是sql server的6倍，B-Tree结构未做具体比较。

    选择Mongodb的理由：
    1:自身具备数据的持久化；
    2：对于数据的插入性能优越，特别是采用不返回值的模式，理论上来讲是一种异步操作；
    3:由于文档存储是k-value方式，所以对于单条记录的查询操作性能不用考虑；

4：对于水平扩展，数据的主从备份均非常容易。

使用Mongodb过程中遇到过的问题：
1：由于存储的内容完全由客户端决定，于是对于一些对字段做更新的操作，比如sql 中的set count=count+1;存在一个并发更新问题，当两个线程同时需要对count字段加1时，两个线程同时查询到的count内容为1,当线程A完成加1后，数据库中实际已经变成2,此时线程B对count进行加1，此时也是2，于时原来是3的内容，最终会变成2。主要原因就在于更新字段时并不会在服务端进行，字段的内容完全是由客户端决定,即更新时并不会像sql server一样，在服务端变量基础上再做操作。

解决方案：对记录增加自定义的锁标识，尝试在记录上增加锁，如果加锁成功，然后再查询，如果锁标识证明是当前线程才进行更新，否则循环尝试加锁。这里有发生死锁的可能，为此在加锁标记时，可以增加一个锁时间，当超过锁时间后，自动解锁，这样可以避免死锁。

2:数据的插入，主要有两种模式，一种是不返回处理结果，一种是返回处理结果，如果我们不太关心返回结果，那么可以获得最高插入性能，对于一些关注处理结果的业务场景，就需要采取返回结果方式。

    3：最好自定义主键，不采用默认的_id值，我们处理一条学生记录，学生记录是唯一的，比如学生ID，如果我们采用默认_id值，那么在插入数据时也会存在并发问题：两个线程同时处理学生A，当时查询时发现数据库中没有学生A的记录，于时就进行插入，由于默认的_id值是自动生成，类似guid或者是自增id，说的通俗点就是会生成一个不重复的key,此时就会插入学生A记录两次，如果我们选用学生ID做为主键，就可以避免此种情况，当第二次尝试插入时，系统会抛出主键重复的异常。

    为什么需要对mongodb驱动重新封装？
    其实无论是samus驱动还是官方驱动，其实功能都各有秋千，samus驱动对数据操作进行了Linq封装，即我们在操作List时，完全可以采用类似Linq一样的语法，这样可以使我们的学习成本降低，官方驱动的特点是针对数据处理有返回值。我们的需求是即需要操作返回值也需要Linq封装，于时我找到了老赵写的easyMongo，但在它的基本上做了一小部分取舍，取舍内容如下：

    1:去掉了如下逻辑，原意是将大多数操作均放在同一连接中处理，但不满足我们的需求；我们直接对外提供一次性执行方法

InsertOnSubmit,UpdateOnSubmit,DeleteOnSubmit
     public void SubmitChanges()
        {
            using (this.Database.Server.RequestStart(this.Database))
            {
                this.DeleteEntities();
                this.UpdateEntites();
                this.InsertEntities();
            }
        }

2:对上面所提到的insert,update ,delete要求有返回值，对于insert提供两种模式，一类是需要返回值一类则不需要。特别是像更新和删除，我们是非常有必要知道它的处理结果，如果不关心结果，我认为可以是一些数据准确性要求不高的场景。

     public EInsertstatus InsertOnSubmit(TEntity entity)
        {
            if (entity == null) throw new ArgumentNullException();
            return this.InsertEntities(entity,ESafeMode.False);
        }
        public EInsertstatus InsertOnSubmit(TEntity entity, ESafeMode safeMode)
        {
            if (entity == null) throw new ArgumentNullException();
            return this.InsertEntities(entity, safeMode);
        }
        public void InsertBatchOnSubmit(List<TEntity> entity)
        {
            if (entity == null) throw new ArgumentNullException();
            this.InsertBatchEntities(entity);
        }
        public bool UpdateOnSubmit(TEntity entity)
        {
            if (entity == null) throw new ArgumentNullException();
            return this.UpdateEntites(entity);
        }
        public bool DeleteOnSubmit(TEntity entity)
        {
            if (entity == null) throw new ArgumentNullException();

            return this.DeleteEntities(entity);
        }

    3:对查询的修改，在将实体映射为mongo文档时，需要对我们自定义的实体提供一个Map，这个Map主要是为了标识哪个是主键，哪些字段是可以被Linq识别的字段，比如我们要按学生ID查询，就需要在Map中增加此字段，示例如下：

public class AggregateCompanyRecruitStudentInfoMap : EntityMap<AggregateCompanyRecruitStudentInfo>
    {
        public AggregateCompanyRecruitStudentInfoMap()
        {
            Collection("AggregateCompanyRecruitStudentInfo");
            Property(n => n.OrganizationID).Identity();
            Property(n => n.LockTime);
            Property(n => n.LockFiled);

        }
    }

但源码中的查询，如果没有提供查询表达式，则默认只返回Map中提到的字段，对其它实体字段则不处理，为此修改如下：即没有查询表达式的情况返回完整文档。

FieldsDocument fieldsDoc = null;
            if (null != selector)
            {
                fieldsDoc = mapper.GetFields(selector);
            }

    4:去掉原有复杂的更新逻辑，删除对我们没用的状态跟踪，要的就是简单直接，过于复杂的逻辑不利于开发。

    Mymongo的一个简化结构图分享给大家：

说明：最后欢迎大家交流mongodb，文中如有不对的地方，希望批评指正，大家共同进步。

本文链接

通过mongodb客户端samus代码研究解决问题

2011-08-04T06:07:00Z

     最近有项目需要用到mongodb，于是在网上下载了mongodb的源码，根据示例写了测试代码，但发现一个非常奇怪的问题：插入记录的速度比获取数据的速度还要快，而且最重要的问题是获取数据的速度无法让人接受。

     测试场景：主文档存储人员基本信息，子文档一存储学生上课合同数据集合，这个集合多的可达到几百，子文档二存储合同的付款记录集合，集合大小一般不会超过50。根据人员ID查询人员文档，序列化后的大小为180K不到，但消耗的时间在400ms以上。

    我的主要问题在于不能接收获取一个180K的记录需要400ms以上，这比起传统的RDBMS都没有优势，而且mongodb也是内存映射机制，没道理性能如此之差，而且网络上关于它的性能测试数据远远好于我的测试结果。

    排除方式一：是不是因为有子文档的原因？
    找一个没有任何合同记录的文档查询，发现结果依旧，没有明显的改善；

    排除方式二：没有创建索引？
    在搜索列ID上创建索引，结果依旧；

   排除方式三：是不是文档数量过大？
   一万多行只是小数目，没理由，mongodb管理上千万的文档都是没有问题的，于时还是决定试一试，将记录全部删除，插入一条记录然后查询，结果依旧；

   排除方式四：是不是由于客户端序列化的问题？
   由于我存储的是自定义的对象，不是默认的Document，所以决定尝试直接存储Document,Document就两个字段，获取速度还是需要180ms。

   排除方式五：是否由于客户机器是32位，而mongodb服务是64？
   将程序放在64位机器上测试，问题依旧。

   排除方式六：是否由于网络传输问题？
   没道理啊，测试的客户端以及服务端均在同一局域网，但还是尝试将客户端程序直接在mongodb服务器上执行，问题一样；

   上面的六种方式都已经尝试过，没有解决，最后决定求助于老代，毕竟是用过mongodb的高人，给我两个建议就搞定了：

   排除方式七：查看mongodb数据文件，看是否已经很大？
   经查看，总大小才64M，这比32位文件上限的2G来讲，可以基本忽略；

   排除方式八：连接字符串。
   Servers=IP:27017;ConnectTimeout=30000;ConnectionLifetime=300000;MinimumPoolSize=8;MaximumPoolSize=256;Pooled=true

   我一看到这个参考字符串，第一印象是，我的写法和它不一样(string connectionString = "mongodb://localhost"; )，然后发现有两个重要的参数：
   1:ConnectionLifetime=300000,从字面意思来看，是说连接的生命周期，而它的数值设置如此大，显然说明此连接不会被立即关闭，这和sql server的做法有所区别；
   2:Pooled=true,从字面意思来看，应该是有连接池的概念。

   分析：从上面的连接参数来看，我之前所理解的连接，就是客户端与服务端之间的连接，它需要在使用完之后马上关闭，即客户端与服务端不在有tcp连接。但我没有很好的理解连接池的作用。连接池实际上从存储很多个已经和服务端建立tcp连接的connection,在它的生命周期内一直保持和服务端的连接，生命周期过后会变成失效连接等待回收。

   重新修改连接字符串再进行测试，问题解决，只有第一次请求时，由于需要创建tcp连接，性能会受影响，后面的请求，因为有连接池的存在，性能得到成倍提高。

   最后看了下samus源码，就可以看出它是如何使用连接池的。

   先看下我写的一个mongodb的帮助类：里面有创建Mongo对象等常规操作。

public class MongodbFactory2<T>: IDisposable where T : class
    {
        //public  string connectionString = "mongodb://10.1.55.172";
        public  string connectionString = ConfigurationManager.AppSettings["mongodb"];
        public  string databaseName = "myDatabase";
        Mongo mongo;
        MongoDatabase mongoDatabase;
        public  MongoCollection<T> mongoCollection;
        public  MongodbFactory2()
        {
            mongo = GetMongo();
            mongoDatabase = mongo.GetDatabase(databaseName) as MongoDatabase;
            mongoCollection = mongoDatabase.GetCollection<T>() as MongoCollection<T>;
            mongo.Connect();
        }
        public void Dispose()
        {
            this.mongo.Disconnect();
        }

        /// <summary>
        /// 配置Mongo,将类T映射到集合
        /// </summary>
        private Mongo GetMongo()
        {
            var config = new MongoConfigurationBuilder();
            config.Mapping(mapping =>
            {
                mapping.DefaultProfile(profile =>
                {
                    profile.SubClassesAre(t => t.IsSubclassOf(typeof(T)));
                });
                mapping.Map<T>();
            });
            config.ConnectionString(connectionString);
            return new Mongo(config.BuildConfiguration());

        }

     从上面的代码中可以看到有这么一句：mongo.Connect()，我第一印象就是创建客户端与服务端的连接，其实有了连接池，这个操作并非每次都创建远程连接，有的情况只是从连接池中直接返回可用连接对象而已。

   从源码分析是如何利用连接池，连接是如何创建的。
   1：Mongo类的Connect函数：需要跟踪_connection对象。

/// <summary>
        ///   Connects to server.
        /// </summary>
        /// <returns></returns>
        /// <exception cref = "MongoDB.MongoConnectionException">Thrown when connection fails.</exception>
        public void Connect()
        {
            _connection.Open();
        }

2：再看这句：return new Mongo(config.BuildConfiguration());

/// <summary>
        ///   Initializes a new instance of the <see cref = "Mongo" /> class.
        /// </summary>
        /// <param name = "configuration">The mongo configuration.</param>
        public Mongo(MongoConfiguration configuration){
            if(configuration == null)
                throw new ArgumentNullException("configuration");

            configuration.ValidateAndSeal();

            _configuration = configuration;
            _connection = ConnectionFactoryFactory.GetConnection(configuration.ConnectionString);
        }

        上面代码的最后一句有_connection的生成过程。
    3:可以跟踪到最终生成connection的函数，终于看到builder.Pooled这个参数了，这的值就是连接串中的参数。

/// <summary>
        /// Creates the factory.
        /// </summary>
        /// <param name="connectionString">The connection string.</param>
        /// <returns></returns>
        private static IConnectionFactory CreateFactory(string connectionString){
            var builder = new MongoConnectionStringBuilder(connectionString);

            if(builder.Pooled)
                return new PooledConnectionFactory(connectionString);

            return new SimpleConnectionFactory(connectionString);
        }

4:再看PooledConnectionFactory是如何创建连接的：这的作用就是将可用连接放入连接池中，而最终真正创建连接的函数是CreateRawConnection()

/// <summary>
        /// Ensures the size of the minimal pool.
        /// </summary>
        private void EnsureMinimalPoolSize()
        {
            lock(_syncObject)
                while(PoolSize < Builder.MinimumPoolSize)
                    _freeConnections.Enqueue(CreateRawConnection());
        }

5:真正远程连接部分。

/// <summary>
        /// Creates the raw connection.
        /// </summary>
        /// <returns></returns>
        protected RawConnection CreateRawConnection()
        {
            var endPoint = GetNextEndPoint();
            try
            {
                return new RawConnection(endPoint, Builder.ConnectionTimeout);
            }catch(SocketException exception){
                throw new MongoConnectionException("Failed to connect to server " + endPoint, ConnectionString, endPoint, exception);
            }
        }
        private readonly TcpClient _client = new TcpClient();
        private readonly List<string> _authenticatedDatabases = new List<string>();
        private bool _isDisposed;

        /// <summary>
        /// Initializes a new instance of the <see cref="RawConnection"/> class.
        /// </summary>
        /// <param name="endPoint">The end point.</param>
        /// <param name="connectionTimeout">The connection timeout.</param>
        public RawConnection(MongoServerEndPoint endPoint,TimeSpan connectionTimeout)
        {
            if(endPoint == null)
                throw new ArgumentNullException("endPoint");

            EndPoint = endPoint;
            CreationTime = DateTime.UtcNow;

            _client.NoDelay = true;
            _client.ReceiveTimeout = (int)connectionTimeout.TotalMilliseconds;
            _client.SendTimeout = (int)connectionTimeout.TotalMilliseconds;

            //Todo: custom exception?
            _client.Connect(EndPoint.Host, EndPoint.Port);
        }

    接着我们来看下，连接的生命周期是如何实现的：主要逻辑在PooledConnectionFactory,如果发现连接已经过期，则将连接放入不可用队列，将此连接从空闲连接中删除掉。

/// <summary>
        /// Checks the free connections alive.
        /// </summary>
        private void CheckFreeConnectionsAlive()
        {
            lock(_syncObject)
            {
                var freeConnections = _freeConnections.ToArray();
                _freeConnections.Clear();

                foreach(var freeConnection in freeConnections)
                    if(IsAlive(freeConnection))
                        _freeConnections.Enqueue(freeConnection);
                    else
                        _invalidConnections.Add(freeConnection);
            }
        }
     /// <summary>
        /// Determines whether the specified connection is alive.
        /// </summary>
        /// <param name="connection">The connection.</param>
        /// <returns>
        ///  <c>true</c> if the specified connection is alive; otherwise, <c>false</c>.
        /// </returns>
        private bool IsAlive(RawConnection connection)
        {
            if(connection == null)
                throw new ArgumentNullException("connection");

            if(!connection.IsConnected)
                return false;

            if(connection.IsInvalid)
                return false;

            if(Builder.ConnectionLifetime != TimeSpan.Zero)
                if(connection.CreationTime.Add(Builder.ConnectionLifetime) < DateTime.Now)
                    return false;

            return true;
        }

        最后我们来看我最上面的mongodb帮忙类的如下方法：即释放连接，而这里的释放也不是直接意义上将连接从客户端与服务端之间解除，只不过是将此连接从忙队列中删除，重新回归到可用队列：

public void Dispose()
        {
            this.mongo.Disconnect();
        }

再看看mongo.Disconnect()

/// <summary>
        ///   Disconnects this instance.
        /// </summary>
        /// <returns></returns>
        public bool Disconnect()
        {
            _connection.Close();
            return _connection.IsConnected;
        }

        继续往下就会定位到如下核心内容：

/// <summary>
        ///   Returns the connection.
        /// </summary>
        /// <param name = "connection">The connection.</param>
        public override void Close(RawConnection connection)
        {
            if(connection == null)
                throw new ArgumentNullException("connection");

            if(!IsAlive(connection))
            {
                lock(_syncObject)
                {
                    _usedConnections.Remove(connection);
                    _invalidConnections.Add(connection);
                }

                return;
            }

            lock(_syncObject)
            {
                _usedConnections.Remove(connection);
                _freeConnections.Enqueue(connection);
                Monitor.Pulse(_syncObject);
            }
        }

        总结：经过各位不同的尝试，终于解决了mongodb查询慢的原因，并非mongodb本身问题，也非网络，非数据问题，而是在于没有正确使用好客户端连接，不容易啊，在此谢谢老代的指点。

本文链接

并行运算学习(1)

2011-07-31T13:24:00Z

     最近有项目对于性能要求非常高，虽然系统大部分都是IO密集型，但也不排除有计算密集型的操作，比如将来在项目中采用了Mongdb，那么将会有非常多的机会对大的泛型集合进行查询，计算(比如sum操作)等，多少能起到一定的性能提升作用,多核心CPU如果不充分利用起来实在有些可惜。

     文中的部分代码均参考Parallel Programming with Microsoft .NET，这篇文章是以第五章后面的习题来分享。题目给了一个思路，对于一个过程是否可以采取并行运算，最好事先画一张流程图，看看哪些部分是可以并行的，即之间没有任何的依赖关系,图中能放在一个水平线上的即表示可以并行的部分。

说明：

1:本文的代码不考虑IO，即全部代码都是在CPU中执行,对于有IO的情况，会在后面的文章中做充分的尝试。
2:测试环境是:Intel(R) Core(TM)2 Duo CPU T9550 @2.66GHZ

     题目：将下面代码并行起来。
     var b = F1(a); var d = F2(c); var e = F3(b,d); var f = F4(e); var g = F5(e); var h = F6(f,g);

     首先我们来看下这6个函数的执行流程图，图中箭头代表依赖方向，线上的字母分别代表输入输出参数。

     分析：从图中可以看出，F1,F2在同一水平线了，同样，F4,F5也在同一水平线上，这说明这两部分是可以并行的。

     测试的核心函数是一个数字累加的过程：

/// <summary>
        /// Simulates a CPU-intensive operation on a single core. The operation will use approximately 100% of a
        /// single CPU for a specified duration.
        /// </summary>
        /// <param name="seconds">The approximate duration of the operation in seconds</param>
        /// <returns>true if operation completed normally; false if the user canceled the operation</returns>
        public static bool DoCpuIntensiveOperation(double seconds)
        {
            return DoCpuIntensiveOperation(seconds, CancellationToken.None, false);
        }

        /// <summary>
        /// Simulates a CPU-intensive operation on a single core. The operation will use approximately 100% of a
        /// single CPU for a specified duration.
        /// </summary>
        /// <param name="seconds">The approximate duration of the operation in seconds</param>
        /// <param name="token">A token that may signal a request to cancel the operation.</param>
        /// <param name="throwOnCancel">true if an execption should be thrown in response to a cancellation request.</param>
        /// <returns>true if operation completed normally; false if the user canceled the operation</returns>
        public static bool DoCpuIntensiveOperation(double seconds, CancellationToken token, bool throwOnCancel = false)
        {
            if (token.IsCancellationRequested)
            {
                if (throwOnCancel)
                    token.ThrowIfCancellationRequested();
                return false;
            }

            long ms = (long)(seconds * 1000);
            Stopwatch sw = new Stopwatch();
            sw.Start();
            long checkInterval = Math.Min(20000000, (long)(20000000 * seconds));

            // loop to simulate a computationally intensive operation
            int i = 0;
            while (true)
            {
                i += 1;

                // periodically check to see if the user has requested cancellation
                // or if the time limit has passed
                if (seconds == 0.0d || i % checkInterval == 0)
                {
                    if (token.IsCancellationRequested)
                    {
                        if (throwOnCancel) token.ThrowIfCancellationRequested();
                        return false;
                    }

                    if (sw.ElapsedMilliseconds > ms)
                        return true;
                }
            }
        }

6个函数内容如下，基本就是些加减法：

/// <summary>
        /// A computationally intensive function
        /// </summary>
        static int F1(int value)
        {
            SampleUtilities.DoCpuIntensiveOperation(2.0);
            return value * value;
        }

        /// <summary>
        /// A computationally intensive function
        /// </summary>
        static int F2(int value)
        {
            SampleUtilities.DoCpuIntensiveOperation(1.0);
            return value - 2;
        }
        /// <summary>
        /// A computationally intensive function
        /// </summary>
        static int F3(int value1, int value2)
        {
            SampleUtilities.DoCpuIntensiveOperation(0.1);
            return value1 + value2;
        }
        /// <summary>
        /// A computationally intensive function
        /// </summary>
        static int F4(int value)
        {
            SampleUtilities.DoCpuIntensiveOperation(1.0);
            return value + 1;
        }


        /// <summary>
        /// A computationally intensive function
        /// </summary>
        static int F5(int value)
        {
            SampleUtilities.DoCpuIntensiveOperation(1.0);
            return value + 5;
        }
        /// <summary>
        /// A computationally intensive function
        /// </summary>
        static int F6(int value1, int value2)
        {
            SampleUtilities.DoCpuIntensiveOperation(1);
            return value1 + value2;
        }

     为了做对比，我分别做了以下几部分测试：
     1:传统的顺序计算；
     2:只将F1并行起来；
     3:只将F4并行起来；
     4:将F1,F4都并行起来。

/// <summary>
        /// Sequential example
        /// </summary>
        public static int Example1()
        {
            var a = 22;
            var c = 11;
            var b = F1(a);
            var d = F2(c);
            var e = F3(b,d);
            var f = F4(e);
            var g = F5(e);
            var h = F6(f, g);
            return h;
        }

        /// <summary>
        /// A parallel example that uses the futures pattern for F1
        /// </summary>
        public static int Example2()
        {
            var a = 22;

            var bf = Task<int>.Factory.StartNew(() => F1(a));
            var c = F2(11);
            var d = F3(bf.Result,c);
            var f =  F4(d);
            var g = F5(d);
            var h = F6(f , g);
            return h;
        }
        /// <summary>
        /// A parallel example that uses the futures pattern for F4
        /// </summary>
        public static int Example3()
        {
            var a = 22;

            var b =  F1(a);
            var c = F2(11);
            var d = F3(b, c);
            var f = Task<int>.Factory.StartNew(() => F4(d));
            var g = F5(d);
            var h = F6(f.Result, g);
            return h;
        }
        /// <summary>
        /// A parallel example that uses the futures pattern for F1/F4
        /// </summary>
        public static int Example4()
        {
            var a = 22;

            var bf = Task<int>.Factory.StartNew(() => F1(a));
            var c = F2(11);
            var d = F3(bf.Result, c);
            var f = Task<int>.Factory.StartNew(() => F4(d));
            var g = F5(d);
            var h = F6(f.Result, g);
            return h;
        }

测试结果:从下图可以非常清晰的看出，在使用并行后，性能得到了明显的提升，如果在release下应该效果会更好。

下面的一个测试，只是写法上的不同，从理论上来讲，和Example4对比没有实质的性能提升。如果两个任务可以并行，我们将其中一个task用并行模式即可。

/// <summary>
        /// 些种写法只是做一个对比，理论上没有性能提升
        /// </summary>
        public static int Example5()
        {
            var a = 22;

            var bf = Task<int>.Factory.StartNew(() => F1(a));
            var c = Task<int>.Factory.StartNew(() => F2(11));
            var d = F3(bf.Result, c.Result);
            var f = Task<int>.Factory.StartNew(() => F4(d));
            var g = F5(d);
            var h = F6(f.Result, g);
            return h;
        }

执行的测试结果图如下：

总结：并行运算是个好东西，主要是需要搞清楚它的适用场景，它主要针对计算型的运算，如果都是些数据库操作之类的IO访问，作用并不是特别大，如果处理的数据量不大，性能也不会有提升，反而也许会有影响，创建线程也是需要开销的，核心的就是确认好适用场景，然后是确认可以并行的部分。对于IO操作，下面的内容我会根据实际情况做些测试，本文有什么不对的地方，希望大家批评指正。

本文链接