分布式会话
什么是会话？
会话Session代表的是客户端与服务器的一次交互过程，这个过程可以是连续也可以是时断时续的。曾经的Servlet时代（jsp），一旦用户与服务端交互，服务器tomcat就会为用户创建一个session，同时前端会有一个jsessionid，每次交互都会携带。如此一来，服务器只要在接到用户请求时候，就可以拿到jsessionid，并根据这个ID在内存中找到对应的会话session，当拿到session会话后，那么我们就可以操作会话了。会话存活期间，我们就能认为用户一直处于正在使用着网站的状态，一旦session超期过时，那么就可以认为用户已经离开网站，停止交互了。用户的身份信息，我们也是通过session来判断的，在session中可以保存不同用户的信息。
无状态会话
HTTP请求是无状态的，用户向服务端发起多个请求，服务端并不会知道这多次请求都是来自同一用户，这个就是无状态的。cookie的出现就是为了有状态的记录用户。
常见的，ios与服务端交互，安卓与服务端交互，前后端分离，小程序与服务端交互，他们都是通过发起http来调用接口数据的，每次交互服务端都不会拿到客户端的状态，但是我们可以通过手段去处理，比如每次用户发起请求的时候携带一个userid或者user-token，如此一来，就能让服务端根据用户id或token来获得相应的数据。每个用户的下一次请求都能被服务端识别来自同一个用户。
有状态会话
Tomcat中的会话，就是有状态的，一旦用户和服务端交互，就有会话，会话保存了用户的信息，这样用户就“有状态”了，服务端会和每个客户端都保持着这样的一层关系，这个由容器来管理（也就是tomcat），这个session会话是保存到内存空间里的，如此一来，当不同的用户访问服务端，那么就能通过会话知道谁是谁了。tomcat会话的出现也是为了让http请求变的有状态。如果用户不再和服务端交互，那么会话超时则消失，结束了他的生命周期。如此一来，每个用户其实都会有一个会话被维护，这就是有状态会话。
场景：在传统项目或者jsp项目中是使用的最多的session都是有状态的，session的存在就是为了弥补http的无状态。
单个tomcat的会话
先来看一下单个tomcat会话，这个就是有状态的，用户首次访问服务端，这个时候会话产生，并且会设置jsessionid放入cookie中，后续每次请求都会携带jsessionid以保持用户状态。
前后端分离的会话
用户请求服务端，由于动静分离，前端发起http请求，不会携带任何状态，当用户第一次请求以后，我们手动设置一个token，作为用户会话，放入redis中，如此作为redis-session，并且这个token设置后放入前端cookie中（app或小程序可以放入本地缓存），如此后续交互过程中，前端只需要传递token给后端，后端就能识别这个用户请求来自谁了。
集群分布式系统会话
集群或分布式系统本质都是多个系统，假设这个里有两个服务器节点，分别是AB系统，他们可以是集群，也可以是分布式系统，一开始用户和A系统交互，那么这个时候的用户状态，我们可以保存到redis中，作为A系统的会话信息，随后用户的请求进入到了B系统，那么B系统中的会话我也同样和redis关联，如此AB系统的session就统一了。当然cookie是会随着用户的访问携带过来的。那么这个其实就是分布式会话，通过redis来保存用户的状态。
SSO单点登录（Single Sign On）
多个不同网站系统，用户只要在其中一个站点登录，那么其他站点也会随之而登录，这就是单点登录。
相同*域名的单点登录
多个网站它们的*域名相同的情况下，例如shop.jinsh.com、music.jinsh.com、movie.jinsh.com，他们的*域名都是www.jinsh.com 。由于*域名相同，因此这几个站点之间的cookie是可以共享的，这样一来，登陆后的用户信息前端通过cookie共享，后端通过redis共享，前后端交互时可以将userId和token携带上，这样只要用户不退出，那么就能在任意一个站点实现登录了。
- 注意：*域名www.jinsh.com 和 *.jinsh.com 的cookie值时可以共享的。但二级域名自己独立的cookie是不能共享的，不能被其他二级域名获取。比如：music.jinsh.com的cookie不能被movie.jinsh.com共享，二者互不影响，要共享必须设置为.jinsh.com.
不同*域名的单点登录
不同*域名的网站之间，由于cookie不能跨域，用户信息无法同步，怎么实现单点登录？我们可以借助CAS（Central Authentication Service即*认证服务）系统，一个单点登录的解决方案。