目前用户的认证多半是基于表单的认证，基于表单的认证一般会使用 Cookie 来管理Session（Session会话，Session代表着服务器和客户端一次会话的过程，直到Session失效（服务端关闭）或者客户端关闭时结束）。基于表单认证本身是通过服务器端的Web应用，将客户端发送过来的用户ID和密码与之前登录过的信息做匹配来进行认证的。
但鉴于 HTTP 是无状态协议， 之前已认证成功的用户状态无法通过协议层面保存下来。 即无法实现状态管理， 因此即使当该用户下一次继续访问，也无法区分他与其他的用户。于是我们会使用Cookie 来管理 Session，以弥补 HTTP 协议中不存在的状态管理功能。
简单的来说就是，用户在登录的时候，会在Web服务器中开辟一段内存空间Session，用于保存用户的认证信息和其他信息，用户登录成功之后会通过Set-Cookie的首部字段信息，通知客户端保存Cookie，而这Cookie保存的就是服务器端Session的ID，下次请求的时候客户端会带上该Cookie向服务器端发送请求，服务器端进行校验，如果Session中保存的有该ID的Session就表示用户认证通过，否则失败！
Session 是存储在Web服务器（例如：Tomcat）中的，并针对每个客户端（客户），通过SessionID来区别不同用户的。Session是以Cookie技术或URL重写实现，默认以Cookie技术实现，服务端会给这次会话创造一个JSESSIONID的Cookie值。
但是这样存在一个显著的问题：在集群模式下，通过Nginx负载均衡的时候，如果有一个用户登录的时候请求被分配到服务器A上，登录成功后设置的Session就会存放在服务器A上了，在服务器B上没有该用户的Session数据；当用户再次发起一个请求的时候，此时请求如果被分配到服务器B上，则就不会查询到该用户的登录状态，就会出现登录失败的情况！
很容易想到的解决方案是将多个Web服务器上存储的Session统一存储到某一存储介质中，保证进集群中的每一台机器都可以看到所有相同Session数据，这里的同步体现在所有的Session存储在同一的存储介质里边。
幸运的是，常用的Tomcat容器已经为我们提供了一个接口，可以让我们实现将Session存储到除当前服务器之外的其他存储介质上，例如Redis等。
Spring Session的本质就是通过实现Tomcat提供的这个接口将Session存储到Redis中，以此来实现Session的统一存储管理。使用Spring Session的方式来实现Session的同步是一件相对比较麻烦的事情，我们虽然使用Redis来进行同步，但是Redis并不是100%可靠的，我们需要对Redis搭建集群、进行主从同步复制、进行持久化等，显然这是一件很复杂的事情。
