如果我们要使用token机制用以标识用户登录状态，以获得请求相关资源接口的权限。让你来设计一套方案，以为怎么设计呢？
通常有两种思路：
1.使用refreshtoken获取新的accesstoken
登录成功之后，返回一个返回refreshtoken和accesstoken。accesstoken作为请求其他接口的权限参数，它有时间期限。过期之后就无法使用。可以使用refresh_token来获取新的accesstoken。
refresh_token也有时间期限，只不过比较长，一般可设置为1天或3天。这种设计方案需要客户端有“token保活机制”，比如accesstoken失效请求失败，则获取新的accesstoken重新请求，对时效性要求可能不是那么高。这种机制一般常见于移动端。
典型的参数
{
“access_token”: “343bec2737979ca0ace85a80c243b1ec”,
“expires_in”: 2592000,
“refresh_token”: “de81cfe747ad7e06f2a904e73646f04c”
}
2.服务端token保活
登录成功之后，只返回accesstoken。accesstoken作为请求其他接口的权限参数，它也有时间期限。不同的是，我们将“token保活机制”做在服务端。在token有效内，如果使用了此token，那么更新token的有效时长，效果相当于重新登录之后的有效时长。web端就非常适合这样的机制。
1.token保活机制设计
token保活机制需要满足下面2个条件
1.登录成功之后，返回一个token。前端所有请求都带上token做鉴权验证。
2.假如token的有效时长是3小时，我们期望的效果是：每用此token请求成功一次，都将token的有效时长自动延长至3小时。
最简单的处理方法是，每成功请求一次，都对token进行put到Redis的操作，重新设置有效时长。简单粗暴。但是我们知道，Redis是一个适合“少写多读”场景的缓存数据库，这样做显然不合适。
而且对于第2条要求，显然没有次次都更新的必要，我们想要的是，在token失效之前的一小段时间，如果有带次token的请求成功，这时我们再进行一次put到Redis的操作。而且我们希望这样的更新操作，不会阻塞请求向前执行。
设计方案：
1.使用过滤器Filter拦截除登录外的所有请求，验证token是否有效，有效才放行
2.我们将token作为key，用户信息还有token上次的请求时间戳作为value，存在Redis中，并设置有效时间。存redis的原因是，1是便于多个服务获取当前用户，2是简单高效。
3.当Fil
