Session or Cookie？是否需要用Tomcat等Web容器的Session
Cookie是HTTP协议标准下的存储用户信息的工具，浏览器把用户信息存放到本地的文本文件中。
Session是基于Cookie实现的。
2011年4月，武汉群硕面试的时候（实习生），面试官也问过这个问题。
当时只知道Session是基于Cookie的，但是没有想到“不使用Tomcat等Web容器的Session，只使用Cookie也可以实现自己的Session，完成会话管理，而且据说性能更好。”
以前的做法：
使用HttpRequestSession保存用户信息，非常方便。
配置一个登录拦截器，从Session中获得当前用户的信息。
如果需要登录，但Session中没有用户信息，就强制跳转到登录页；否则，正常执行。
如果不需要登录，无论Session是否有用户信息，正常执行。
好处：使用自带的Session，编程更方便，不需要额外处理。
坏处：性能不好，据说Session占居的内存会非常多。
之前做的Web项目，用户都不大，没有考虑过这个问题。
为了实现“保持登录”这个功能，要用到Cookie，需要做一下特殊处理。
Tomcat的Session可以存放到Redis中，保证服务器重启的情况下，已经登录的用户仍然保持登录。
把Java的Session存到Redis，这个还没有实现过。
创业的做法：
创业做ITFriend的时候，我们是把Node.js的Session数据存到Redis中。
现在的做法：
不使用HttpRequestSession，使用Cookie，在用户端保存key，用户信息缓存到Redis中。每次请求来的时候，根据Cookie信息，得到key，根据缓存，判断用户是否登录过。
配置一个登录拦截器，默认需要登录。使用@LoginNeedless注解，就不需要登录。无论是否登录，都可以把用户的信息放到线程上下文ThreadLocal<User>中。
在实际过程中，发现一个问题，ThreadLocal<User>是线程局部变量，但是Tomcat的线程是“线程池” 实现的，两个不同用户的ThreadLocal可能是同一个，
因此在请求和开始的时候，清空用户信息： LoginUtil.setCurrentUser(null);
防止不同用户的数据互相干扰。
理论上的性能排序：
Cookie+Redis >= 容器Session+Redis > 容器Session
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
