【Spring Security系列】Spring Security集群会话的解决方案

本文链接：https://blog.csdn.net/qq_28248897/article/details/107067184

本文探讨了Spring Security在集群环境中解决会话问题的三种方案：session保持、session复制和session共享。session保持通过IP哈希策略可能导致负载失衡；session复制在大规模集群中带来资源浪费。相比之下，session共享更实用，它将session存储在独立的数据容器（如Redis）中，确保各服务器实例间的一致性。Redis的高性能和高可用性使其成为内网环境的理想选择。

摘要由CSDN通过智能技术生成

解决集群会话的常见方案有三种：

session保持

session复制

session共享

session保持也叫粘滞会话（Sticky Sessions），通常采用IP哈希负载策略将来自相同客户端的请求转发至相同的服务器上进行处理。session保持虽然避开了集群会话，但也存在一些缺陷。例如，某个营业部的网络使用同个IP出口，那么使用该营业部网络的所有员工实际的源IP其实是同一个，在IP哈希负载策略下，这些员工的请求都将被转发到相同的服务器上，存在一定程度的负载失衡。

session复制是指在集群服务器之间同步session数据，以达到各个实例之间会话状态一致的做法。但毫无疑问，在集群服务器之间进行数据同步的做法非常不可取，尤其是在服务器实例很多的情况下，任何变动都需要其他所有实例同步，不仅消耗数据带宽，还会占用大量的资源。

相较于前两种方案，session 共享则要实用得多。session 共享是指将 session 从服务器内存抽离出来，集中存储到独立的数据容器，并由各个服务器共享，由于所有的服务器实例单点存取session，所以集群不同步的问题自然也就不存在了，而且独立的数据容器容量相较于服务器内存要大得多。另外，与服务本身分离、可持