分布式 session 的4个解决方案

服务端存储

实现：session复制（session同步）

就是让这两个服务器之间互相同步session，比如左边服务器之前保存了一个1，右边服务器之前保存了一个2，他们两个一同步，那么左边服务器保存了1,2，右边服务器也保存了1,2。

优点：

1. tomcat原生支持，只需要修改一下配置文件，好多tomcat之间就能复制session

缺点

1. session同步需要通过网络进行数据传输，就有延迟问题，同时会占用大量带宽，这样会压缩我们整个业务的带宽，会降低我们的处理能力

如果是大型分布式集群环境，由于所有的web-server都全量保存数据，所以这种方案我们不使用。而如果是小型系统里面，就3/5个tomcat，我们想使用的话，就简单配置一下也还可以

客户端存储

实现：

我们让客户端自己来存储session，我们服务器想用哪些数据，读取浏览器带过来的cookie即可。这样可以节省服务器资源

缺点

1. 每次http请求，携带用户在cookie中的完整信息，浪费网络带宽
2. session数据放在浏览器的cookie中，有些浏览器遵循的标准不一样，它的长度限制不一样，比如长度限制4k，因此不能保存大量信息
3. session数据放在cookie中，存在泄露、篡改、窃取等安全隐患

HASH一致性（推荐）

原理：

利用了我们负载均衡机制，我们可以利用ip的哈希一致性，只要来自于同一个ip的，那我们就永远给它定位到同一个服务器，我们也不给它跑到第二个服务器了，这样比如标绿色的浏览器去的标绿色的服务器里面存的东西，无论多少次请求过来，都会落到标绿色服务器的身上，我们就能取得到

优点

1. 只需要改负载均衡nginx的配置，让它做一个ip hash，而不需要修改应用代码
2. 负载是均衡的：只要hash属性的值分布是均匀的，多台web-server的负载就是均衡的
3. 支持web-server水平扩展（而session复制方案是不行的，受内存限制）

缺点

1. session还是存在web-server中，因此web-server突然闪断或者重启了，可能会导致部分session丢失，这部分用户只要下次再过来，所有的数据都没了，他需要重新登录一遍，所有东西都得重新做一遍
2. 如果我们服务器要水平扩展，如果我们固定了也好，但是如果原来是2台服务器，现在加到了4台服务器，现在想要做哈希的话，相当于重新得计算一下，假设我们以前计算哈希最简单的方式，按照ip地址得到一个整数型的哈希，如果只有2台服务器，那么就可以对2求余操作，求到余数，如果余数是1，就落到第一台服务器，如果没有余数，就落到第二台服务器。但如果变成了4台服务器，我们相当于就要对4进行求余操作，如果余1，落到第一台服务器，余2落到第二台服务器，余3落到第三台服务器，没有余数我们落到第四台服务器。（即水平扩展后，rehash后session重新分布，会有一部分用户路由不到正确的服务器）

统一存储（推荐）

实现：

那我们就可以让session统一存储，无论是你哪个服务器，哪个tomcat，你的session都不要存储到你的内存里面了，全部呢，大家都可以存到数据库，或者redis之类的速度更快的nosql中间件等等，所以，我们可以使用这种方案

优点

1. 没有安全隐患，没有让浏览器自己存储到cookie里，所有的数据都是我们后台统一存储，浏览器肯定是没办法访问到的，只要我们保障了我们后台的redis的安全，就没有人能去篡改里面相关的数据

2. 水平扩展也很容易，无论我们web服务器有多少个，10个，100个，1000个，反正大家都去redis中做存取，即使redis不够用了，我们做redis集群，每个里面存一点，每个里面存一点

3. 我们服务器即使重启、宕机，下次再启动了，我们session也不会丢失，因为session都是redis里面存着，跟我们业务服务器宕机与否没有任何关系

缺点

1. 从内存中取数据是非常快的，也不需要网络交互，而如果我们存储到了redis里面，我们想要从session里面取数据，我们还得连接redis，再来一次网络交互

2. 我们需要修改应用代码：如将所有的getSession方法替换为从Redis查数据的方式

原文链接：https://mp.weixin.qq.com/s/wX5wmn8Wykxt4_bxzZrJ6Q