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

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

• session保持
• session复制
• session共享

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

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

相较于前两种方案，session 共享则要实用得多。session 共享是指将 session 从服务器内存抽离出来，集中存储到独立的数据容器，并由各个服务器共享，由于所有的服务器实例单点存取session，所以集群不同步的问题自然也就不存在了，而且独立的数据容器容量相较于服务器内存要大得多。另外，与服务本身分离、可持久化等特性使得会话状态不会因为服务停止而丢失。当然，session共享并非没有缺点，独立的数据容器增加了网络交互，数据容器的读/写性能、稳定性以及网络I/O速度都成为性能的瓶颈。基于这些问题，尽管在理论上使用任何存储介质都可以实现session共享，但在内网环境下，高可用部署的Redis服务器无疑为最优选择。Redis基于内存的特性让它拥有极高的读/写性能，高可用部署不仅降低了网络I/O损耗，还提高了稳定性。