【Spring Security系列】Spring Security集群会话的缺陷

会话通常保存在服务器内存中，客户端访问时根据自己的sessionId在内存中查找，这种方法虽然简单快捷，但缺点也很明显。从容量上来说，服务器内存有限，除了系统正常运行的消耗，留给session的空间不多，当访问量增大时，内存就会捉襟见肘。从稳定性上来说，session依赖于内存，而内存并非持久性存储容器，就算服务器本身是可靠的，但当部署在上面的服务停止或重启时，也会导致所有会话状态丢失。当然，这两个缺点还只是体验性缺陷，并不足以影响可用性，在单机部署时为 了节省精力忽略这两个问题也是可以的。但当我们的系统采用集群部署时，就会有更多关于可用性的问题需要考虑。

大部分的集群部署会采用类似下图所示的网络结构。

在这种网络结构下，用户的请求首先会打在Nginx服务器上,服务器再根据负载策略将这些请求转发至后面的服务，以达到请求分散的目的。正常来说，在集群环境下，同个用户的请求可能会被分发到不同的服务器上，假如登录操作是在Tomcat1完成的，即Tomcat缓存了用户的登录状态，但Tomcat2和Tomcatn并不知情，如果该用户的后续操作被分配到了Tomcat2或Tomcatn上，这时就会要求该用户重新登录，这就是典型的会话状态集群不同步问题。