分布式一致性session的实现方式
分布式一致性Session
随着系统规模的扩大，系统通常会由单机部署，变为多机部署，通常会使用到nginx作为反向代理。但是由于使用到nginx作为反向代理，就容易出现session一致性的问题。
在我们每次登陆过后，会把用户的登录信息放在Session中，用户每次操作首先先校验Session中是否存在用户信息，如果不存在就会强制让用户先去登录。
当我们部署了多台系统后，由于Nginx使用默认负载均衡策略（轮询），请求会按照时间顺序逐一分发到后端应用上。
这就可能导致用户信息存放到session的Tomcat和请求的Tomcat不一致的问题，由于新的Tomcat没有登录信息就让用户重新登录，从而出现反复登录的问题。
分布式一致性的解决方法
Session复制
正如字面意思所说，一个Tomcat上有了登录信息的session就将其复制到其他的Tomcat中。而且Tomcat还支持Session的复制配置，只需要修稿Tomcat的配置即可，比较简单方便。
缺点
这种方法简单是简单，但是缺点还是很明显的：
- Session复制传输需要占用内网带宽
- 如果机子太多，可能形成网络风暴，复制性能也会呈指数级下降
- Tomcat需要保存所有的Session数据，这个方案的Session存储在内存中，容易受到机器的总内存的限制。而且我们没有办法通过加机器的方式水平扩展，只能加大机器内存。
Session前端存储
正如上面分析的那样Session复制虽然方便但是缺点也还是很明显的。其实仔细分析下就知道我们的session中其实就是存了用户的信息，那么完全可以不由Tomcat来存储Sesssion而是把消息拿出来，存到浏览器的Cookie中。
这样一来，每个用户浏览器存储自己的Cookie信息，服务器不需要存储，这样就解决了Session复制方案的缺陷。
接下来用户每次请求都会把这个Cookie给发过来，然后判断Cookie里面用户的信息。
缺点
- 用户信息是敏感数据，需要加密保证
- 我们存储的数据大小，容易受到Cookie的限制
Session粘滞
可以修改Nginx的配置，将其默认的负载均衡策略，使用IP Hash方式。Nginx会使用请求者的IP来做Hash。然后分发到一台机器上，这样可以保证同一IP的请求都落到同一台Tomcat。
不仅仅可以使用IP做hash还可以使用Http协议中的一些业务属性来做Hash，常见的还有userId，loginId。
后期如果机器扛不住，直接加机器后只需要修改Nginx配置即可。
缺点
- 对于同一IP，请求会打到同一台机器上，相当于单点
- 如果Tomcat重启，部分Session会丢失，将重复登录
- 加完机器后，修改Nginx的配置后，将重新计算Hash分发请求，导致Session丢失
后端集中存储
由于前面的方法都是将Session存储到应用内存中，应用机器只要重启，Session就会丢失，为了避免这种情况，可以将Session单据存起来，保存到Redis或者Mysql中。
由于Session需要过期失效的特性，不需要持久化保存，所以这里我们将其存储到Redis中进行保存。
后期可以直接水平扩展，如果Redis扛不住了，看一眼做集群扩展，根据缓存Key做路由
缺点
- 由于每次请求都需要调用一个Redis，这就增加一次网络的开销
- 另外引入Redis，我们需要对相应的代码做出修改，这样复杂度就变高
彩蛋
如果大家对后端集中存储Session的实现感兴趣的话，就请多多点赞收藏评论，要是反响好的话，下周就出一份如何实现的教程。
最后
- 如果觉得看完有收获，希望能给我点个赞，这将会是我更新的最大动力，感谢各位的支持
- 欢迎各位关注我的公众号【java冢狐】，专注于java和计算机基础知识，保证让你看完有所收获，不信你打我
- 如果看完有不同的意见或者建议，欢迎多多评论一起交流。感谢各位的支持以及厚爱。