在单体应用进行跨页面共享数据，一般常用的方法是使用HttpSession，在没有关闭页面之前，整个session的数据都是实时共享存在的，其原理大致可以参考下图
在分布式中，每个服务都有自己的域名，所以每个服务都有自己的cookie作用域，而cookie只在它自己的作用域中存在，也就是说session不能跨作用域共享；即使在同一个服务中，如果这个服务部署在多个服务器上，在一个服务器存的session，但是在其他服务器是没有这个session的，当负载均衡转发到其他服务器当然是找不到session的，也就是说同一服务复制多份存在session不同步问题
当然有问题就得解决，接下来就聊聊如果解决这些问题
session复制
例如我们访问同一个服务，当负载均衡到以一个服务器产生了session，使用使用session复制方法将这个服务器的session同步复制到其他的服务器上，这样当负载均衡到其他服务器上依旧可以使用到这个session
优点
web-server(tomcat)原生支持，只需要修改配置文件即可
缺点
1. session同步需要数据传输，占用大量网络带宽，降低了服务器集群的业务处理能力
2. 任意一台web-server都保存了所有web-server的session总和，受到内存限制无法水平扩展更多的web-server
3. 大型分布式集群下，所有web-server都保存全量数据，这种方案不可取，当然如果只有几个服务还是可以考虑此方案的
客户端存储
所谓客户端存储，就是将服务返回的数据存在浏览器的cookie中，浏览器请求服务时将cookie带上，服务直接读取浏览器带来的cookie就行了
优点
服务器不用保存session，用户保存自己的session信息到cookie中，节省服务器资源
缺点
1. 每次http请求，都需要携带用户cookie中的完整信息，浪费网络带宽
2. session数据存在cookie中，而cookie的长度只有4K，不能保存大量信息
3. session保存在cookie中，存在泄露、篡改、窃取等安全隐患
hash一致性
利用负载均衡，将用户的请求全部转发到同一个服务器上，例如识别用户的ip地址，用户ID等唯一的身份识别，利用负载均衡机制，将他所有的请求固定的转发到同一个服务器上，在同一个服务器上就不用担心session不存在的问题了
优点
1. 只需要修改NGINX的配置，不需要修改应用代码
2. 负载均衡，只要hash属性的值分布均匀，多态web-server的负载就是均衡的
3. 可以支持web-server的水平扩展
缺点
1. session依旧存在在web-server中，如果服务重启，可能导致session丢失，影响业务
2. 如果web-server水平扩展，rehash后session重新分布，也会有部分用户路由不到正确的session
统一存储
上面的方法，由于负载均衡机制会跳转到不同的服务，而session是每个服务储存各自的内存空间的，所以导致跳转到不同的服务时，上一个服务的session不存在当前服务中，所以可以让session统一存储，无论是哪个服务，都不用将session存在它自己的内存中，而是将session存在数据库中如Redis或者中间件等
优点
1. 没有安全隐患
2. 可以水平扩展，数据库/缓存水平切分即可
3. web-server重启或扩容都不会有session丢失
缺点
1. 增加一次网络调用，并且需要修改应用代码
