关于ASP.NET Session State Server

最近公司开发的一个网站因为访问量增大，需要添加多台Web Server来进行负载均衡。

但是在做负载均衡前需要将一些原来固定存储在单台机器上的东西分离出来，使之能单独存在在一个独立的机器上，其中就有Session State。

Session这个东西有它的优点也有缺点：

优点首先是它是存放在服务器的，不用像Cookie那样每次都要回发到浏览器，占用额外的网络带宽；况且这个Cookie的大小也是有限制的；

其次是Session里面可以存放一些复杂的.Net的对象；另外，ASP.NET的Cache，还有ASP.NET MVC里的TempData，都是基于Session的。

缺点是如果我们采用进程内(InProc，ASP.NET的默认方式)Session，那么首先它容易丢失，因为服务器上的ASP.NET工作进程会不定期或定期做回收，一旦回收，那么Session即丢失；

另外一个缺点是进程内Session既然是存放在进程内的，那么即使是多个ASP.NET工作进程也无法共享Session，更别谈多台机器了；也就是在多工作进程/多机器环境下，用户因为每次请求都是被Load Balancer通过

某种策略分配到不同的机器上（除非Load Balancer启用了某种IP Stickness特性），那么会出现某些请求在服务器端读不到Session的情况。

解决进程内Session带来的这些问题的方法有很多，但作用都是讲Session保存在进程外的其它地方。

常用的方式有将Session保存在数据库里，ASP.NET State Server里，或者使用第三方的Session存放方案，比如使用MemCache等内存存储框架。

从性能上来说，进程内的Session最高，ASP.NET State Server其次，存放在数据库里最低。这个也很好理解，因为进程内的和ASP.NET State Server的都是放在内存里。

从稳定性来说，当然是放在数据库里最稳定，这个理论上来说不存在Session丢失的可能性；最差的是进程内的Session, 工作进程一旦挂掉，Session就全丢失。ASP.Net State Server也是介于两者之间。

由此看来抛开使用第三方Seesion解决方案的情况不看，使用ASP.NET State Server是一种从性能和稳定性来说都算折中的方案。

不过在切换到ASP.NET State Server前还需要注意，如果Session里存放了非.Net原生类型的数据（也就是用户自定义类型），需要将类标识为可序列化(Serializable)，因为ASP.NET会通过二进制序列化来将对象

序列化后再发送到ASP.NET State Server保存。同时，记得放开防火墙对ASP.NET State Server使用的端口的限制(默认是42424端口，可以修改)；还有就是ASP.NET State Server提供了几个用于监控性能的

性能计数器，可以通过性能监视器实时查看ASP.NET State Server的运行状况。