共计 1873 个字符，预计需要花费 5 分钟才能阅读完成。
分布式 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 数据的一致。使用这个方案有以下优缺点：
优点
- 实现简单，只需要少量配置
- 即使某台机器宕机或者重启也不影响用户访问
缺点
- 需要依赖支持 Session 同步的 Web 服务器，如果 Web 服务器不支持就不能使用了
- 存在延迟，因为要等待 Session 同步过来，特别是在数据量比较大的情况下更加明显
- 在服务器集群达到数千台的时候，就会出现瓶颈，因为每台机器都会对外广播自己的 Session，同时要接收其他几千台机器发出的 Session，非常损耗性能。
- 数据冗余非常严重，几千台服务器就有几千份冗余数据，浪费了相当多的资源
适用场景：服务器比较少且 Session 数据量少
Session 集中管理
通过单独的服务器集群来存储和管理 Session 数据，例如 redis，其他所有的应用服务器都从这个存储集群获取对应的 Session，从而实现 Session 的共享。
优点
- 可靠性较高，通过单独的集群进行统一管理
- 减少应用服务器的资源开销
缺点
- 实现较为复杂，配置较多
- 需维护单独的存储集群
适用场景：应用服务器较多、可用性要求较高
每个方案都各有其适用的场景，大家在实际使用过程中需要根据实际情况进行选择
参考资料
http://blog.itpub.net/69951287/viewspace-2664889/
Enjoy it !
如果觉得文章对你有用，可以赞助我喝杯咖啡~
版权声明
转载请注明作者和文章出处
作者: X 先生
https://segmentfault.com/a/1190000022707530
