实现了 HttpSesson，那么我们先将该 session 类叫做 MySession（当然实践中不是这么命名的），当 MySession
出现之后问题才开始，怎么能在不影响业务逻辑代码的情况下，还能让原本的 request.getSession（）获取到的是
MySession，而不是服务器原生的session。这里，我决定重写服务器的HttpServletRequet，这里先称为MyRequest，
但是这可不是单纯的重写，我需要在原生的 request 基础上重写，于是我决定在 filter 中，实现 request 的偷梁换柱，
我的思路是这样的，MyRequest 的构建器，必须以 request 作为参数，于是我在 filter 中将服务器原生的 request（也
有可能是框架封装过的 request），当做参数 new 出来一个 MyRequest，并且 MyRequest 也实现了
HttpServletRequest 接口，其实就是对原生 request 的一个增强，这里主要重写了几个 request 的方法，但是最重要
的是重写了 request.getSession()，写到这里大家应该都明白为什么重写这个方法了吧，当然是为了获取 MySession，
于是这样就在filter中，偷偷的将原生的request换成MyRequest了，然后再将替换过的request传入chan.doFilter()，
这样 filter 时候的代码都使用的是 MyRequest 了，同时对业务代码是透明的，业务代码获取 session 的方法仍然是request.getSession（），但其实获取到的已经是 MySession 了，这样对 session 的操作已经变成了对 redis 的操作。
这样实现的好处有两个，第一开发人员不需要对 session 共享做任何关注，session 共享对用户是透明的；第二，filter
是可配置的，通过 filter 的方式可以将 session 共享做成一项可插拔的功能，没有任何侵入性。

占座00000000000000000