登录的演变

单机时代

如果熟悉javaee的话，我们最开始会使用session来唯一标识一个访问者。默认时间30分钟。他的实现是web服务通过jsessionid做唯一标志。我们做的例如防止重复提交等操作都是依靠session来实现的。整体的样式如下

集群时代1

随着业务的增多，单台服务器慢慢已经满足不了业务的发展了，例如单个服务器的tps只有2w，当客户超多2w的时候，就得排队或者拒绝，于是开始了水平扩展的方式，这样就带来了一个问题。当A客户第一次访问的时候，是web1接受请求的，于是进行了一次登录，A再次请求的时候，负载到了web2,虽然A传递了jsessionid过来，但是B并没有对应的信息，此时又要求A登录一次，返回了另外一个jsessionid,A拿着新的jsessionid去访问服务1，但是服务1里也没有这个session信息，于是服务变得不可用了。主要是登录信息在每个客户端之间无感知，导致了问题，最简单的方法就是让用户A一直访问web1。于是切分的做法开始了。

这种切割的方式就依靠负载，把A的一直给1，B的一直给2。例如根据省份ip来hash。
不同的省份的访问量也不一样，A省的访问5000,B省的访问50。在分割不均匀的情况下，仍然不能完全避免，而且浪费机器资源。于是提出了session共享的做法。保证大家访问后，任意一个节点都可以知道信息。

无论哪个节点，信息都从远处的redis取，这样保证了登录信息都可以共享。

集群时代2

以上方案虽然可以解决问题，但是如果访问量继续增大呢，服务不停的增多，登录信息也不停的变多，此时redis的内存也撑不住了。证明数据的集中处理都是有限的，于是提出了token机制，就是把登录信息用一种加密的方式保存，每个服务器都可以正常解析，token里都存有用户信息，过期信息，这样不论哪个服务器都可以解析出数据，只要能解析成功，并且时间没有过期，那就证明这个用户已经登录了，成功解决了登录信息过多导致的膨胀问题。
但是此时的设计变了，如果想做到防止重复提交，选择的方式不能依赖登录信息，因为服务1和服务2都可能收到连续点击的数据，所以最终的数据压力放到了db这层。

小结

session的单机玩法在业务量小的时候完全可以work，但是访问大的时候可以考虑redis这种缓存，再大的时候就得自己验证自己了，数据得有自己标识自己的方法。