简述
通常的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也是可以胜任的。
