分布式Session一致性问题与JWT的强制失效方案

Session一致性解决方案

利用 Cookie 记录 Session

将session存储到浏览器cookie中。

缺点：

• 极其容易被窃取，不安全
• 受Cookie的大小限制

Session 复制

多台服务器间相互同步 session，这样每台服务器都包含全部的session。

优点：

• 任何一台服务器宕机都不会丢失session

缺点：

• session同步需要数据传输，有延迟
• 浪费内存

Session 绑定

对客户端 IP地址做 hash（如 nginx 的 ip_hash），将 Session 与某一服务器绑定，保证该客户端的每次请求都落在同一服务器上。

优点：

• 负载均衡，只要hash够平均
• 不需要修改服务器代码，只需要修改nginx配置

缺点：

• 某个服务器宕机后，对应的session就会丢失
• 水平扩展服务器后，session会被rehash，客户端可能拿不到正确的session

集中存储 Session(推荐)

将所有session都放在一个独立的缓存服务器中，如Redis。Spring Session 提供了一套完整的解决方案。

JWT 的强制失效方案(不完美)

“Actually, JWT serves a different purpose than a session and it is not possible to forcefully delete or invalidate an existing token.”

实际上，完美地失效 JWT 是无法做到的。

参考：https://medium.com/devgorilla/how-to-log-out-when-using-jwt-a8c7823e8a6

以下是参考国外Blog、Stack OverFlow 和 jjwt GitHub Issues 总结的 jwt 强制失效方案：

1. 将 jwt 存入DB（如Redis）中，失效则删除；但增加了一个每次校验时候都要先从 DB中 查询 jwt 是否存在的步骤，同时违背了 jwt 的无状态原则
2. 维护一个 token 黑名单
3. 增加一个版本号字段，失效则改变该版本号
4. 在服务端设置加密的 key 时，为每个用户生成唯一的 key，失效则改变该 key