Session的缺点总结及解决方法

 Session有些局限制性，或者说是一些缺点吧。现在我们再来看看Session的缺点：
　　①当mode="InProc"时，也就是默认设置时，容易丢失数据，为什么?因为网站会因为各种原因重启。
　　② 当mode="InProc"时，Session保存的东西越多，就越占用服务器内存，对于用户在线人数较多的网站，服务器的内存压力会比较大。
　　③当mode="InProc"时，程序的扩展性会受到影响，原因很简单：服务器的内存不能在多台服务器间共享。
　　④虽然Session可以支持扩展性，也就是设置mode="SQLServer"或者mode="StateServer"，但这种方式下，还是有缺点：在每次请求时，也不管你用不用会话数据，都为你准备好，这其实是浪费资源的。
　　⑤ 如果你没有关闭Session，SessionStateModule就一直在工作中，尤其是全采用默认设置时，会对每个请求执行一系列的调用。浪费资源。
　　⑥并发问题，前面有解释，也有示例。
　　⑦当你使用无 Cookie 会话时，为了安全，Session默认会使用 重新生成已过期的会话标识符 的策略，此时，如果通过使用 HTTP POST 方法发起已使用已过期会话 ID 发起的请求，将丢失发送的所有数据。这是因为 ASP.NET 会执行重定向，以确保浏览器在 URL 中具有新的会话标识符。

　　不可否认的是，或许有些人认为这些缺点是可以接受的，他们更看中Session的简单、易使用的优点，那么，Session仍然是完美的。

不使用Session的替代方法

　　对于前面我列出的Session的一些缺点，如果您认为你有些是不能接受的，那么，可以参考一下我提出的替代解决方法。
　　①如果需要在一个页面的前后调用过程中维持一些简单的数据，可以使用<input type="hidden" />元素来保存这些数据。
　　②您希望在整个网站都能共享一些会话数据，就像mode="InProc"那样。此时，我们可以使用Cookie与Cache相结合做法，自行控制会话数据的保存与加载。具体做法也简单：为请求分配置一个Key(有就忽略)，然后用这个Key去访问Cache，以完成保存与加载的逻辑。如果要使用的会话数据数量不止一个，可以自定义一个类型或者使用一个诸如Dictionary, HashTable 这样的集合来保存它们。很简单吧，基本上这种方式就是与mode="InProc"差不多了。只是没有锁定问题，因此也就没有并发问题。
　　③ 如果您想实现mode="StateServer"类似的效果，那么可以考虑使用memcached这类技术，或者自己写个简单的服务，在内部使用一个或者多个Dictionary, HashTable来保存数据即可。这样我们可以更精确的控制读写时机。这种方法也需要使用Cookie保存会话ID。
　　4. 如果您想实现mode="SQLServer"类似的效果，那么可以考虑使用mongodb这类技术，同样我们可以更精确的控制读写时机。这种方法也需要使用Cookie保存会话ID。如果您没用使用过mongodb，可以参考我的博客： MongoDB实战开发 
　　从前面三种替代方法来看，如果不使用Session，那么Cookie就是必需的。其实Cookie本身就是设计用来维持会话状态的。只是它不适合保存过大的数据而已，因此，用它保存会话ID这样的数据，可以说是很恰当的。事实上，Session就是这样做的。
　　推荐方法：为了保持网站程序有较好的扩展性，且不需要保存过大的会话数据，那么，直接使用Cookie将是最好的选择。
　　由于Cookie保存在浏览器，且不安全，所以建议只保存诸如：id, key 之类的简单数据，需要其它的会话数据时再根据这些id, Key去获取。
　　到这里，我想我可以回答标题中的问题了：Session，其实是没有必要使用的，不用它，也能容易地实现会话数据的保存。