【IT168 技术文档】在一个基于ASP.NET的Web应用程序中，我们通常使用SessionState保存基于某个客户端的状态信息。但是这种单纯使用SessionState的编程方式具有很多局限，比如Session Item的Key值冲突，比如没有一个有效的SessionState清除机制会为Web Server带来内存压力。为了实现对客户端状态的有效管理，并提高应用开发效率，在很多年前我们的开发框架体系中就具有相应的一个叫做State的编程框架。最近我开始对其进行升级和重新设计，将实现原理和概要设计方面的东西写出来与大家共享，希望对各位有些启发。同时希望借此得到你们一些好的建议和意见，以便能够充实我们的框架。于此同时，我写了一个简单的模拟程序实现了该设计思想，有兴趣的话可以通过这里下载该模拟程序。
一、单纯基于SessionState编程的局限性
SessionState对于ASP.NET的开发者在熟悉不过了，我们可以通过它来存储一些基于客户端的状态信息。从编程角度来说，SesssionState是依附和当前HttpContext的一个用于类似于字典的数据容器，我们通过键值对的方式进行Session Item的设置和获取。但是这种单纯地基于字典索引的编程方式，具有诸多局限：
· 首先，这种弱类型的编程方式不便于快速开发需求。放入SessionState的值是一个System.Object类型的对象，在获取的使用我们需要进行手工转型;而Session Item的Key是手工指定的字符串，如果没有对Key值进行有效的分配，在进行设置的时候很容易造成一个Key值得冲突，从而导致整个状态的混乱;在获取某个Session Item的时候，你指定的Key值可能和预先指定的不符。
· 其次，统一的SessionState的清除机制的缺乏导致服务端内存压力。在默认的情况下(采用InProc会话模式)，SessionState存储于服务端内存，如果过多、过大的Session Item常驻内存，势必会为服务端带来内存压力。实际上，基于客户端的所有的Session Item并不是在整个Session存续期间都是必须的，很多Session Item仅仅是在某几个少数的Web页面中使用。但是我们不能通过程序手工地将其从SessionState中删除，因为我们不能确定该Session Item在那一刻不再需要，因为这往往取决于UI交互的行为。如果太多的低频率使用的Session Item存在，并且它们还不小，服务端内存过多地被占用必要导致性能的下降。
· 最后，如果你采用State Server或者SQL Server会话管理模式，还会造成更多的性能问题。这样的性能损失包括：Session Item的序列化和反序列化、序列化后的Session Item在Web Server和State Server或者SQL Server的网络传输、针对State Server或者SQL Server的数据存取(保存和提取)等。
实际上，我们的State框架还是建立在SessionState基础之上，但是它能够很好的解决上述的三大难题：
· 通过配置为所有使用到的状态项(状态属性名称、数据类型等)提供结构化的定义，并通过基于该结构化配置提供的代码生成使强类型编程成为可能。这比较类似于ASP.NET中Profile的配置和强类型编程的方式;
· 提供状态的后备存储(Backing Storing)机制将低频率使用的大对象从SessionState中移到相应的后备存储(比如文件、数据库)中，从而缓解服务端内存压力;
· 提供灵活的后备策略定义方式以实现基于具体运行环境的最优配置。后备策略主要包括两方面的内容，其一是怎样的状态项需要被后备存储，其二采用怎样的方式进行后备存储。确定后备存储状态项的因素包括：自最近一次被访问以来的超时时限(通过使用频率判断状态项再次被使用的可能性);需要被后备存储对象必须具有的最小字节数(后备存储小对象毫无意义) ;以及状态项的作用域(很多状态项的作用范围仅仅限于某一个相关的Web页面，或者基于某个基地址)等。而具体采用的后备存储方式决定于配置的“后备存储器”，比如在我提供的例子中采用的是基于文件的存储方式，你可以编写基于数据库的后备存储器。
二、通过状态后备存储机制解决Web Server内存的压力
状态的后备机制是整个状态编程框架的核心。通过对所有状态项的扫描，标记出所有需要进行后备存储的状态项。然后将它们进行序列化，并借助于指定的后备存储器将它们存储到相应的物理存储介质。最后，相应的状态会从SessionState中删除，从而缓解了Web Server的内存压力。除了将序列化的状态对象进行后备存储之前，后备存储器还负责从相应的存储介质中提取状态数据。
简单起见，我们并没有在后台运行一个实施后备检测操作的引擎，而是直接通过事件注册的方式让每一个请求自动去触发基于本会话的后备存储，我们注册的事件是HttpApplication的PostRequestHandlerExecute。出于性能的考虑，当事件PostRequestHandlerExecute被触发的时候，并不是总是立即执行后备状态项的检查。而是设置一个相邻两次后备检查的间隔，只有超出这个间隔的情况下，才会进行真正地区检查那些状态向需要进行后备存储了。状态项的后备存储紧接着在后备对象的检查之后进行。
我们通过一个具体的例子来进一步说明后备存储的过程。如左图(点击看大图)所示，在Web Server的IIS进程中的SessionState中维持着三个状态项：Foo、Bar、Baz。当Web Server接收并执行来自浏览器的HTTP请求后，PostRequestHandlerExecute事件的处罚激活了我们的后备检查管理器，它发现状态项Baz最近一次被访问的时间到当前时间的间隔已经超出了设置的超时时限，并且计算出该对象的总字节数超过了设定的下限，就会将该对象标记为后备存储对象。在这种情况下，状态项Baz的值，同它的Key一并进行序列化并进行后备存储。最后将该Baz从SessionState中移除。
如果该Web应用使用Web Farm部署方式，并采用了Sate Server或者SQL Server的会话模式，在同步到Sate Server或者SQL Server的时候，由于SessionState中缺少了Baz这个大对象，也会因为少了对它序列化、网络传输和数据存取使性能得到相应的提升。
