分布式session一致性解决方案

本文主要是介绍分布式session一致性解决方案，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

分布式Session一致性问题

在早期的时候，很多网站由于用户规模较小，都是采取的单机部署的模式，只用一台服务器来承载用户的请求，这时候Session是存在同一台服务器上，所以能够很容易实现会话跟踪和保持。然而随着用户规模的扩大，单机部署模式已经无法承载所有用户的请求了，这时候人们自然而然想到用多台服务器来处理用户的请求，用户的请求会先到达负载均衡，然后再被转发到某个具体应用服务器上进行处理。这时候我们就会遇到一个问题，每次处理同个用户的请求的服务可能不同，那怎么让它们的Session数据保持一致呢？

一般来说有以下四种方案：

Cookie存储Session
Session粘滞
Session复制
Session集中管理

我们来一个一个了解它们的优劣和使用场景

分布式Session一致性解决方案

Cookie存储Session

我们知道Cookie总只有一份的，而且是存在用户端的，所以我们可以通过Cookie来存储Session信息，这样不管最后发送到哪台服务器处理，我们都能通过Cookie取到Session信息。使用这个方案有以下优缺点

优点

简单易用，无需额外的配置
无需额外的外部存储

缺点

为了数据不被泄露，一般需要进行加密，加解密过程需要一定开销
Cookie长度和数量有限制，会限制数据的存储
每次请求都多出来了Session的数据，需要消耗更多网络带宽和系统性能
受限于Cookie的开闭，如果用户关闭Cookie，Session就失效了，用户也就无法正常访问了

适用场景：数据量小的情况。

Session粘滞

也就是粘性Session，当用户访问负载均衡时，通过某种方法算出该用户应该访问的后端服务器，例如通过hash算法。这样保证了每个会话都在同一台服务器上。使用这个方案有以下优缺点：

优点

使用简单，只需要配置好转发规则即可。
没有额外网络开销

缺点

存在单点问题，一但某台机器重启或宕机，相对应的Session数据将会丢失
会话标识是应用层的信息，则负载均衡器要将同一个会话的请求都保存到同一个Web服务器上的话，就需要进行应用层（七层）的解析，这个开销比第四层的交换要大。或许有同学会说，nginx 四层转发可以支持ip hash的方式，这样就能通过四层转发了。事实上最好的方案是通过会话id进行hash，因为在日常生活中还是很容易出现ip发生变化的情况，例如从家里出去的时候，我们手机连接的网络从wifi切换到无线流量会发生ip变化，这时候通过ip hash的方式就会丢失Session了。
负载均衡器变为了一个有状态的节点，需要计算会话和具体Web服务器的映射，因此内存消耗会更大

适用场景：机器数适中、对稳定性要求不是非常苛刻的情况

Session复制

既然只有一台机器存Session容易出现单点问题，那么我们就所有机器都存Session，每台机器间进行Session同步，这样不管访问到哪台机器都能获得Session。这就是Session复制方式，我们给服务器之间增加了会话数据的同步，通过同步来保证不同服务器之间的Session数据的一致。使用这个方案有以下优缺点：

优点