token在服务器端保存客户信息,Token的常用实现方式

简述

通常的Token在服务器端的实现方式有这几个：

用SessionID实现Token的功能

生成Token存在数据库(关系型数据库)

生成Token存在Redis(非关系型数据库)

使用Json Web Token (JWT)

下面分析一下各个存储方式的优缺点

Session

对于每个会话，服务器会生成Session保存在服务器上，而对应的SessionID自动通过HTTP头中的Set-Cookie返回保存在浏览器等客户端中，每次请求客户端都会带上SessionID，然后服务器通过SessionID找到Session判断用户状态。

优点：

操作简单，一般小项目使用起来完全没问题

缺点：

Session文件可能需要共享。当需要多个服务器做负载均衡时麻烦就来了，由于Session以文件方式存储在服务器硬盘中，就会出现只有一个服务器存在会话Session文件，而其他服务器没有该会话的Session文件的情况。

(解决该问题可以参考https://www.cnblogs.com/wangtao_20/p/3395518.html)

一些客户端不会自动保存和发送SessionID，如小程序，需要手动在请求头Set-Cookie中加上

生成Token并存在数据库(关系型数据库)

如字面意思，就是手动生成Token串存在数据库中，将Token返回客户端并且每次客户端请求都带上这个Token。

优点：

由于Token在数据库中而不像Session存在本地，方便管理与多服务器支持。

缺点：

验证效率问题。每次验证用户状态都要走数据库，增加了数据库的负担，不过在用户量不是特别庞大的情况下没问题(毕竟大部分用户请求都要经过数据库，顺便验证一下问题不大)

生成Token并存在Redis(非关系型数据库)

也是手动生成Token，但这次是存在Redis中而不是关系数据库中。

优点：

由于Token在Redis中而不像Session存在本地，方便管理与多服务器支持。

由于Redis跑在内存中，验证效率快上很多

缺点：

Redis的快的优点也导致了它的缺点，Redis跑在内存中，一旦Redis服务器崩了，此时一些数据就会丢失

使用Json Web Token (JWT)

简单来说JWT就是通过可逆加密算法，生成一串包含用户、过期时间等关键信息的Token，每次请求服务器拿到这个Token解密出来就能得到用户信息，从而判断用户状态。

优点：

无论哪个服务器解出来的Token信息都一样，而且不需要做任何查询数据库操作，省掉了数据库/Redis的开销

缺点：

无法主动更新Token的有效性，只要用户传回来的Token没有过期，服务器就会认为这个用户操作是有效的。比如一下这个场景：某用户被封禁，此时该用户所有操作都应该被禁止，但是由于之前发给用户的JWT Token还没有过期，服务器仍然认为该用户操作合法。有一个解决方案是维护一张JWT黑名单表，只有没在表上的用户的JWT是有效的。但是随之而来又有一个问题便是这个JWT黑名单表存在哪里。存在服务器，那么又要搞多服务器同步。存在关系数据库，那么查数据库效率又低。存在Redis，则又回到了Token丢失问题。。

其实解析JWT Token也是消耗服务器CPU的

总结

个人意见是大型项目可以使用Token+Redis/Token+数据库，这个Token可以是自己生成，也可以是JWT Token，只不过验证还是走Redis/数据库。对于要求不高的项目，Session/JWT也是可以胜任的。