这个时候已经实现了一套可插拔的 session 共享的框架了，但是我们想到如果 redis 服务出了问题，这时我们该怎
么办呢，于是我们延续 redis 的想法，想到可以将 session 维护在客户端内（加密的 cookie），当然实现方法还是一
样的，我们重写 HttpSession 接口，实现其所有方法，比如 setAttribute 就是写入 cookie，getAttribute 就是读取
cookie，我们可以将重写的 session 称作 MySession2，这时怎么让开发人员透明的获取到 MySession2 呢，实现方
法还是在 filter 内偷梁换柱，在 MyRequest 加一个判断，读取 sessionType 配置，如果 sessionType 是 redis 的，那
么 getSession 的时候获取到的是 MySession，如果 sessionType 是 coolie 的，那么 getSession 的时候获取到的是
MySession2，以此类推，用同样的方法就可以获取到 MySession 3,4,5,6 等等。
这样两种方式都有了，那么我们怎实现两种 session 共享方式的快速切换呢，刚刚我提到一个 sessionType，这
是用来决定获取到session的类型的，只要变换sessionType就能实现两种session共享方式的切换，但是sessionType
必须对所有的服务器都是一致的，如果不一致那将会出现比较严重的问题，我们目前是将 sessionType 维护在环境变
量里，如果要切换 sessionType 就要重启每一台服务器，完成 session 共享的转换，但是当服务器太多的时候将是一
种灾难。而且重启服务意味着服务的中断，所以这样的方式只适合服务器规模比较小，而且用户量比较少的情况，当服
务器太多的时候，务必需要一种协调技术，能够让服务器能够及时获取切换的通知。基于这样的原因，我们选用
zookeeper 作为配置平台，每一台服务器都会订阅 zookeeper 上的配置，当我们切换 sessionType 之后，所有服务
器都会订阅到修改之后的配置，那么切换就会立即生效，当然可能会有短暂的时间延迟，但这是可以接受的。

我来占层楼啊   

占座00000000000000000