Redis存储session共享在远光天鹊的实践

有人问，远光天鹊作为一个数据集成产品，是怎么实现会话共享的？
其实我们实现会话共享有很多种方案。

在分布式集群应用中通常通过配置会话保持等设置来保证用户持续访问，这样配置具有简单快捷的优点，但可能会出现应用负载分配不均的情况，从而导致某些节点繁忙，某些节点闲置，而且稳定性有待考量。今天我们来介绍远光天鹊的另一种实现方案：使用redis存储来实现session共享。

Spring Session是Spring家族中的一个子项目，Spring Session提供了用于管理用户会话信息的API和实现。它把servlet容器实现的httpSession替换为spring-session，专注于解决 session管理问题，Session信息存储在redis中，可简单快速且无缝的集成到我们的应用中。

首先，要在web.xml配置过滤器。

springSessionRepositoryFilter
org.springframework.web.filter.DelegatingFilterProxy


springSessionRepositoryFilter
/*

然后，根据文档实现redis相关配置信息加载。

以上是根据sping官方帮助文档操作来使用redis实现Session 共享，但有时候生产环境没有redis或者redis配置错误怎么办，这时又要使用此前的旧方案进行会话保持，但是很显然目前做的这些事只能使用redis 来存储Session，这就需要我们进行一些改造来满足没有redis的环境还能正常启动的需求。
来看下Spring Session的原理：

可以看出关键点在DelagatingFilterProxy这个入口，阅读DelegatingFilterProxy的源码，发现这个类名副其实，就是一个委托过滤器代理，目的是通过配置过滤器的名称查找真正实现功能的Filter，然后完成该Filter的功能。找不到过滤器时就会直接抛出异常导致整个应用启动失败。如果有没有redis环境，那远光天鹊数据集成平台岂不是使用不了？显然这样实现是不合理的。

来，我们将原来的代码进行改造，设置一个@ComponentScan扫描redis配置所在的包，通过自定义excludeFilter来控制是否扫描redis相关的配置Bean,excludeFilter内的逻辑则是尝试读取redis配置，没有配置redis或者尝试连接redis失败则不会创建redis配置的相关Bean，也就不会创建SessionRepositoryFilter。

继承DelegatingFilterProxy，重写initDelegate和invokeDelegate方法，未找到SessionRepositoryFilter时进入过滤器链的下一个过滤器逻辑。

这样我们的远光天鹊就完美的实现在有redis的情况下使用redis做session共享，和没有redis的情况下可以使用其他的会话共享方案（不至于无法启动），远光天鹊使用redis做会话共享就是这么简单。