整理-Session一致性的几种解决方案

什么是session一致性问题？

假设用户包含登录信息的session都记录在第一台server上，反向代理如果将请求路由到另一台server上，可能就找不到相关信息，而导致用户需要重新登录。

session一致性的几种解决方案

session同步（复制）

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

session数据存储在客户端cookie

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

反向代理hash一致性
原理：利用反向代理使得同一个用户的请求落在一台固定的服务器上，不要发生服务器切换即可，服务器之前内存session中的数据还是在的；可以有两种实现；
四层代理ip_hash
原理：反向代理层使用用户ip来做hash，以保证同一个ip的请求落在同一个web-server上

七层代理根据http协议任意业务字段自定义hash
原理：反向代理使用http协议中的某些业务属性来做hash，例如sid，city_id，user_id等，能够更加灵活的实施hash策略，以保证同一个浏览器用户的请求落在同一个web-server上

优缺点
优点：
只需要改nginx配置，不需要修改应用代码
负载均衡，只要hash属性的值分布是均匀的，多台web-server的负载是均衡的
可以支持web-server水平扩展（session同步法是不行的，受内存限制）
缺点
session还是存在web-server中的，所以web-server重启可能导致部分session丢失，影响业务，如部分用户需要重新登录
如果web-server水平扩展，rehash后session重新分布，也会有一部分用户路由不到正确的session
但是以上缺点问题也不是很大，因为session本来都是有有效期的。所以这两种反向代理的方式可以使用

后端统一存储session数据
原理：将session存储在web-server后端的存储层，数据库或者缓存；但是由于session是频繁读取的数据而且有过期时间，所以我们一般存在Redis缓存中，而不是MySQL等db中

优点：
没有安全隐患
可以水平扩展，数据库/缓存水平切分即可
web-server重启或者扩容都不会有session丢失
不足
增加了一次网络调用，并且需要修改应用代码；如将所有的getSession方法替换为从Redis查数据的方式

总结
保证session一致性的架构设计常见方法：
session同步法：多台web-server相互同步数据
客户端存储法：一个用户只存储自己的session数据到cookie中
反向代理hash一致性： 做，保证一个用户的请求落在一台web-server
后端统一存储：web-server重启和扩容，session也不会丢失