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损耗，还提升了稳定性。