分布式session有以下几种方案：

1. 基于nfs(net filesystem)的session共享

将共享服务器目录mount各服务器的本地session目录，session读写受共享服务器io限制，不能满足高并发。

2. 基于关系数据库的session共享

这种方案普遍使用。使用关系数据库存储session数据，对于mysql数据库，建议使用heap引擎。 这种方案性能取决于数据库的性能，在高并发下容易造成表锁（虽然可以采用行锁的存储引擎，性能会下降），并且需要自己实现session过期淘汰机制。

3. 基于cookie的session共享

这种方案也在大型互联网中普遍使用，将用户的session加密序列化后以cookie的方式保存在网站根域名下（比如taobao.com），当 用户访问所有二级域名站点式，浏览器会传递所有匹配的根域名的cookie信息，这样实现了用户cookie化session的多服务共享。 此方案能够节省大量服务器资源，缺点是存储的信息长度受到http协议限制；cookie的信息还需要做加密解密； 请求任何资源时都会将cookie附加到http头上传到服务器，占用了一定带宽。

4. 基于resin/tomcat/iis等web容器的session机制

利用容器机制，通过配置即可实现。

5. 基于zookeeper的分布session存储

详见http://my.oschina.net/u/699015/blog/159654

6. 基于redis/memcached的session共享存储

这些key/value非关系存储有较高的性能，轻松达到2000左右的qps，内置的过期机制正好满足session的自动实效特性。

 

以上方案各有优缺点，本文主要介绍第六种基于redis存储session时，如何实现动态扩容。 redis目前并没有内置高可用集群，很多客户端代理基于一致性hash算法能够实现分布式存储，但是扩容并不方便（需要成倍扩容），目前我们采用了淘宝 fourinone中session方案的思想：

a. 用于存储session的redis集群有多个redis节点

b. proxy记录了每个节点加入到集群的时间，并按照时间顺序对节点进行了编号(0—n)

c. session key的生成算法方面，需要在session key中包含生成时的当前日期（可考虑细化到小时还是分秒），在session key生成后，再进行取模运算  hash(sesionKey)%redisHost_count,  根据取模结果决定当前session值存储到落到哪个节点上存储。

d. 再通过sessionkey获取session信息时，根据当前sessionKey取出时间部分，再根据取出的时间与redis集群中所有的节点的添加 时间进行比较，筛选出所有addtime<sessionkey_time的节点，再进行c中的取模计算，由于即使这期间进行了扩容，由于进行了时 间匹配，redisHost_count也不会发生变化，所以取模结果和存储此session时一样，还会落到当时存储这个session的节点上，在那 个节点能够得到此session的值。

但是对于这种部署结果如何能够保障高可用性，如何应对单点故障，后续会在redis高可用方案中介绍。