传统实现方式：
一般单台服务器下用户登陆后直接在服务器保存用户的session信息。然后前端请求后台的时候携带用户的cookie信息过来，服务器通过JESSIONID参数查找session信息。如果可以查找到session信息，说明用户是有效的登陆状态，无需用户重复登陆，如果查找不到session信息则说明用户尚未登陆或者登陆态已经失效需要重新登陆。
传统方式为什么不建议使用？
当应用面向大量的用户，并发量大且需要为用户提供24小时不间断的服务时，建议采用集群的架构。在集群架构下，用户的请求就有可能落到不同的服务器上，假设用户登陆的时候请求的是A服务器，session则记录在A服务器上。如果用户其他的操作如出单落在了B服务器上，那么根据JESSIONID在B服务器上查找session信息就会查询不到。这样就会让用户在此登陆。影响用户体验。
解决方案：
基于上面的案例问题，可以采用Token的概念替代了Session。并且没有把Token信息保存在应用服务器上，而是保存在了redis服务器中。之所以用redis因为redis为单线程的缓存服务器，支持大并发高速查询。
Token同时在用户登陆成功后返回给前端，以后前端每次查询都会携带Token信息。服务器接受到用户的Token后，根据Token查询Redis服务器是否存在用户信息，如果存在，则说明用户已登陆。这样即使用户在A服务器登陆，在B服务器上通过Token也可以查询到用户的登陆信息，就不必重复登陆了。完美解决了传统方式导致用户重复登陆的问题。
Token 信息安全问题解决方案：
用户每次登陆的Token信息都是不同的，生产规则是根据用户ID(用户唯一标识)+时间戳+随机数等信息拼接并通过aes加密。并且前后端采用https通讯方式避免劫持。所以不会存在安全性的问题。