记一次分布式环境下TOKEN实现用户登录

背景：

以前的单体项目，使用的是session来保存用户登录状态，控制用户的登录过期时间等信息，但是这个session是只保存在该服务器的这个系统内存中。系统只有一个服务就没关系，但是如果是分布式的服务，每个服务都有一个自己的session，传统的做法就无法判断用户的登录状态了，也有解决办法，就是服务之间的session复制，但是代价太大了，开发成本高、难以维护。所以分布式服务下我们一般使用当下比较流向的redis+token实现用户登录。

解决方案：

解决方案分两种情况，第一种：单点登录（一个用户一个token），第二种：多客户端登录（一个用户多个token）

单端登录：

单端登录，会更加安全，用户同时只能在一个客户端登录。token生成，这个就不说了，网上代码一大堆，保持随机性和唯一性就可以。整个单点登录的具体实现思路如下：

1. 当用户登录时，且账号密码正确
   1.1. 后端根据用户ID删除redis中1.2生成的两个键值对，用户ID获取token，根据token再删除（实现的是用户重新登录后，上一次登录状态作废，实现了同时只能有一个客户端在线）
   1.2. 后端生成一个token，往redis存两个带过期时间（一般是2小时）的键值对，分别为 key：token，value:用户信息、key：用户ID，value：token。第一个键值对用来判断用户登录状态是否过期，第二个键值对便于获取用户信息。
   1.3. 后端最后将token返回到响应头中
2. 前端解析返回的响应头，获取token,将token存储在cookie中（默认20分钟过期）
3. 前端在登录后的发送的请求，都需要在请求头中赋值token（前端请求拦截器实现）
4. 后端设置网关拦截器
   4.1. 拦截除白名单（自己配置，因为有的请求不需要校验token，比如登录）外的请求
   4.2. 判断请求是否有token且该token能否在redis中找到，如果有token则放行该请求，且设置响应头赋值token。token不存在则返回登录过期（此处于前端约定登录过期的状态）
   4.3. 判断请求中的token存在，且距离redis设置的过期时间不到五分钟（此处灵活设置），重新生成token（一定时间更换token，提高安全性），执行1.2操作，将redis中老的token设置过期时间为30秒（解决并发请求，其他请求还在拦截器处理中）
   4.4. 将4.3操作加redis分布式锁，锁的粒度为用户级，防止同一用户多次刷新token
5. 前端设置响应拦截器，当后端返回登录过期时，跳转到登录页，提示登录过期。当后端返回正常时，获取响应头的token,刷新cookie里的token

多客户端登录

多客户端，用户可同时在多个客户端登录。token生成，这个就不说了，网上代码一大堆，保持随机性和唯一性就可以。整个多客户端登录的具体实现思路如下：

1. 当用户登录时，且账号密码正确
   1.1. 后端正常生成新的token，存入redis（实现的是用户重新登录后，上一次登录状态依旧存在，实现了同时有多个客户端在线）
   1.2. 后端生成一个token，往redis存两个带过期时间（一般是2小时）的键值对，分别为 key：token，value:用户信息、key：用户ID+token，value：token。第一个键值对用来判断用户登录状态是否过期，第二个键值对便于获取用户信息。
   1.3. 后端最后将token返回到响应头中
2. 前端解析返回的响应头，获取token,将token存储在cookie中（默认20分钟过期）
3. 前端在登录后的发送的请求，都需要在请求头中赋值token（前端请求拦截器实现）
4. 后端设置网关拦截器
   4.1. 拦截除白名单（自己配置，因为有的请求不需要校验token，比如登录）外的请求
   4.2. 判断请求是否有token且该token能否在redis中找到，如果有token则放行该请求，且设置响应头赋值token。token不存在则返回登录过期（此处于前端约定登录过期的状态）
   4.3. 判断请求中的token存在，且距离redis设置的过期时间不到五分钟（此处灵活设置），重新生成token（一定时间更换token，提高安全性），执行1.2操作，将redis中老的token设置过期时间为30秒（解决并发请求，其他请求还在拦截器处理中）
   4.4. 将4.3操作加redis分布式锁，锁的粒度为用户+token级，防止同一客户端用户多次刷新token
5. 前端设置响应拦截器，当后端返回登录过期时，跳转到登录页，提示登录过期。当后端返回正常时，获取响应头的token,刷新cookie里的token