NET下Session共享的几种实现方式

一、把用户ID加密存储在Cookie中

1．  把用户ID，用可逆加密的方式，存储于Cookie中。当用户登陆成功时，ID经过加密存储。用户第一次访问A页面，通过解密ID，如果解密成功，然后调用SOA（或者其他分布式服务实现，可以达到随意扩展，而不用更改调用端），获取用户信息，然后把用户信息存储在Session中，如果这时用户从A页面跳转到B页面，同样可以通过解密获取用户信息。这样导致的问题是，大量访问登陆服务，降低了Session的利用率。如果能实现，同一个用户固定负载均衡到同一台服务器上，就可以实现比较高的Session利用率。

2．  可以随时更换密钥，但是必须所有服务器都使用相同的密钥，否则会出现混乱。

3．  如果客户端禁用Cookie将产生致命问题。

4．  Cookie容量有限，存储的数据量必须要严格控制,并且把一组信息写到同一个Cookie中，避免过多的Cookie。

二、把Session写到Memcache、Redis等分布式共享缓存中。

1．  必须实现分布式缓存的容灾机制，否则一台机器挂掉，将导致大量用户不能登陆。

2．  并且要能水平扩展，这将导致分布式缓存的维护成本上升。

三、把Session存放在数据库中。

1．  可靠性高，进程挂掉，也能处理。

2．  需要单独程序的实现，数据库开销大。

3．  数据库会是单点，可以用Hash的方式解决。

四、NET提供把Session存储在内存中。

1．  可以是单独的存储Session的服务器的内存中，也可以是和IIS同一台机器的内存中，集群化实现比较困难，如果Session存放在单独一台机器，其也是单点，有风险；如果存放和IIS同一台机器上，集群化有实现不易，负载均衡受制，必须保证同一个用户，一直访问同一台机器才能保证Session。

五、NET也提供把Session存储在IIS进程中。

1．  问题同把Session存放在内存中。

2．  同时由于和IIS共有进程，可能由于IIS的问题导致Session无法使用问题，崩溃的几率上升。

六、无聊想法自定义的Session解决方案。

1．  把用户ID加密存储在Cookie中，通过“方式一”，解密得到用户ID，然后把用户相关信息，存储在Memcache/Redis等上，用户再次访问时，优先从分布式缓存上取用户更多信息，如果没有从数据库中去取，然后同时以异步的方式把用户信息，缓存，而且分布式缓存的淘汰算法，是最近最少使用法。其实现方式是封装在基类中，在分布式缓存上，存储基于ID的key/Value数据。即使挂掉也可以从数据库中恢复用户的主要信息。

2．  该方式是基于加密算法和分布式缓存的结合体。

七、NET的Session值的共享，需要在配置machineKey。

1． 配置sessionState置节点，使用StateServer或SQLServer来实现Session共享。

为实现跨服务器共享，必须在Web.config配置：

<machineKey decryptionKey="FD69B2EB9A11E3063518F1932E314E4AA1577BF0B824F369" validationKey="5F32295C31223A362286DD5777916FCD0FD2A8EF882783FD3E29AB1FCDFE931F8FA45A8E468B7A40269E50A748778CBB8DB2262D44A86BBCEA96DCA46CBC05C3" validation="SHA1" decryption="Auto"/> ；即要求集群有相同的值。