方式

1、通过Redis设置时间过期

登陆

        后端通过客户端的特征信息做md5加密，生产digest并存入Redis，设置EXP，比如2小时，生成无过期时间的Token返回前端

后续请求

        后端通过客户端特征信息做md5加密，生成digest并到Redis查询：

1. 如果有值且ttl剩余1小时以上则不续签，处理token负载内容；
2. 如果有值且ttl剩余不到1小时则续签，比如续签1小时，处理token负载内容；
3. 如果无值，表示客户端特征信息有假不存在或者超过2小时Redis已经删除，返回401

2、双Token机制

        如图所示，生成两个Token，access_token负责后端业务验证，refresh_token负责续签验证，所以从逻辑上各司其职并不是脱裤子放屁。

登陆

        派发access_token、refresh_token，其中access_token过期时间是1小时，而refresh_token过期时间是2小时，且二者负载内容一致。

后续请求

        access_token未过期则后端正常执行业务，当access_token过期时再验证refresh_token，如果refresh_token未过期则续签，即派发新的access_token、refresh_token到客户端

问题

        如果1s内发送了多个请求到后端，如果按照上面的流程执行，可能会出现客户端突然获取多个新token且层层覆盖的情况，对于后端是一个性能损耗的bug

解决

1. 记录新token的客户端信息，如果记录里面没有发现原始token，则生成新token并记录原始token和新token，再设置过期时间比如3s；
2. 如果发现了和请求的原始token相同的记录，则直接返回记录里的新token，再重新设置过期时间3s