jwt与token+redis，哪种方案更好用

1. 问题描述jwt与token+redis，哪种方案更好用？
问题结论刚好最近有项目使用了jwt，而且是定制化的jwt的认证机制，就个人的理解而言，各自有其优缺点，并且针对不同的场景需要进行约束性开发，如用户剔除、同一用户每2h只生成一次jwt等。
2. Token机制简述2.1 Token的用途用户在登录APP时，APP端会发送加密的用户名和密码到服务器，服务器验证用户名和密码，如果验证成功，就会生成相应位数的字符产作为token存储到服务器中，并且将该token返回给APP端。
以后APP再次请求时，凡是需要验证的地方都要带上该token，然后服务器端验证token，成功返回所需要的结果，失败返回错误信息，让用户重新登录。
其中，服务器上会给token设置一个有效期，每次APP请求的时候都验证token和有效期。
在存储的时候把token进行对称加密存储，用到的时候再解密。
文章最开始提到的签名sign：将请求URL、时间戳、token三者合并，通过算法进行加密处理。
2.2 token+redis机制用户验证通过后，服务端通过如uuid相关的方法，生成token，存储用户信息。
当请求服务时，客户端将token带上来，进行查询验证，如token存在并在有限期内，请求有效，否则请求非法。
token + redis机制是中心化的，每次验证token有效性时，都需要访问redis，其核心优点实服务端可以主动让token失效，缺点是每次都要进行redis查询。
占用redis存储空间。
2.3 jwt机制这是一种无状态身份验证机制，因为用户状态永远不会保存在服务器内存中。
服务器受保护的路由将在授权头中检查有效的JWT，如果存在，则允许用户访问受保护的资源。
由于JWT是独立的，所有必要的信息都在那里，减少了多次查询数据库的需求。
Java jwt普遍选用java-jwt工具包依赖，gradle依赖：compile 'com.auth0:java-jwt:3.2.0'用户发起登录请求，验证通过后，服务端创建一个加密后的JWT信息，作为Token返回。
在后续请求中JWT信息作为请求头，发给服务端。
服务端拿到JWT之后进行解密，正确解密表示此次请求合法，验证通过；
解密失败说明Token无效或者已过期。
jwt的有点主要有：a.其是去中心化的，便于分布式系统使用；
2. 基本信息可以直接放在token中。
user_id，session_id；
3. 功能权限信息可以直接放在token中。
用bit位表示用户所具有的功能权限。
其缺点有：服务端无法主动让token失效，另一个是无法很好的控制payload的数据量。
3. 小结jwt和token+redis两种方案，没有最优，只有结合不同的业务场景，需求最适合的方案。
就比如token 2h过期，同一用户每1.5h只生成一次token，当两次token并存时，同时有效。
大家可以考虑在这两种方案的前提下，分别如何实现？
作者：夕阳雨晴，欢迎关注我的头条号：偶尔美文，主流Java，为你讲述不一样的码农生活。