SpringSession - 分布式Session解决方案及SpringSession基本使用

分布式Session的几种解决方案

1、Session复制

Tomcat服务器互相同步session。
优点：
web-server (Tomcat) 原生支持，只需要修改配置文件
缺点：
1、session同步需要数据传输，占用大量网络带宽，降低了服务器群的业务处理能力
2、任意一台web-server保存的数据都是所有web-server的sesdion总和，受到内存限制无法水平扩展更多的web-server
3、大型分布式集群情况下，由于所有web-server都全量保存数据，所以此方案不可取。

2、客户端存储

将session存储在cookie中。
优点：
服务器不需存储session,用户保存自己的session信息到cookie中，节省服务端资源。
缺点：
这只是一种思路，不会使用该方式，具体原因如下：
1、每次http请求，携带用户在cookie中的完整信息，浪费网络带宽。
2、session数据放在cookie中，cookie有长度限制4K,不能保存大量信息。
3、session数据放在cookie中，存在泄漏、算改、窃取等安全隐患。

3、Hash一致性

利用ip_hash的一致性，浏览器不变，IP不变，让每一次访问都落在同一个服务器上。同时也可以配合id值，比如图中的sid=456的请求每次落在第一个服务器，sid=123的请求每次落在第二个服务器。
优点：
1、只需要改nginx配置，不需要修改应用代码。
2、负载均衡，只要hash属性的值分布是均匀的，多台web-server的负载是均衡的。
3、可以支持web-server水平扩展(session同步法是不行的，受内存限制)。
缺点：
1、session还是存在web-server中的，所以web-server重启可能导致部分session丢失，影响业务，如部分用户需要重新登录。
2、如果web-server水平扩展，rehash后session重新分布,也会有一部分用户路由不到正确的session。
但是以上缺点问题也不是很大，因为session本来都是有有效期的。所以这两种反向代理的方式可以使用。

4、统一存储

将session存储到数据库(Redis)中，每次都从数据库中获取。
优点：
1、没有安全隐患
2、可以水平扩展，数据库/缓存水平切分即可
3、web-server重启或者扩容都不会有session丢失
缺点：
增加了一次网络调用，并且需要修改应用代码;如将所有的getSession方法替换为从Redis查数据的方式，redis获取数据比内存慢很多
上面缺点可以用SpringSession完美解决

5、不同服务，子域Session共享

jsessionid这个cookie默认是当前系统域名的。当我们分拆服务，不同域名部署的时候，我们可以使用如下解决方案：

第一次使用Sess