会话管理
HTTP的基本性质
- HTTP是简单的
- HTTP是可扩展的
- HTTP是无状态,有会话的
多次请求之间彼此是没有联系的,如果想要请求之间有联系,使其 成为一个整体,可以使用Cookies解决问题
HTTP本质是无状态的,使用cookies可以创建有状态的会话。
Cookie
- 是服务器发送到浏览器,并保存在浏览器端的一块数据
- 浏览器下次访问该服务器,会自动携带块该数据,将其发送给服务器
一般的数据存在cookie中是没问题的,但是像密码这一些重要的数据,不建议存储在cookie,可以使用session存储
Session
- 是JavaEE的标准,用于在服务端记录客户端信息
- 数据存放在服务端更加安全,但是也会增加服务端的内存压力
session依赖于cookie,但其数据是存放于服务端的,虽然会给服务端一定的压力,但是,其数据会更安全
总结
要想实现业务连续,要记录浏览器的状态,到底采用session还是cookie这得看具体的实际情况来定。但总体来说,能使用cookie还是尽量使用cookie,这样能减小服务端的压力。再一个,如果是没必要存储cookie的,就没必要去存,可以通过 cookie.path 设置一个 cookie 的生效范围来限制。
- 问题:采用分布式部署的时候,为什么不采用session?
- 因为采用分布式部署,一台浏览器会分配多态服务器来对其业务进行处理,这样就需要在浏览器与服务器之间进行一个负载均衡处理(添加一个nginx)
- 当浏览器访问服务器时,可能当前访问第一台服务器有空,它来处理,那么就会在服务器创建一个session。但是当第二次访问时,可能就不是第一台服务器处理了,那么就会在新的服务器创建session,这样就不能实现业务的连续;
这样的解决方法有三个:
① 设置负载均衡分配的策略,也叫**粘性session :**就是说把固定的 sessionid 分给固定的的服务器去处理,这样能保证session的业务连续。但是同一个 sessionid 分给固定的服务器,那么分布式部署就无法确定 负载是均衡的;不完美
② **同步session:**当一个服务器创建 session 时,它会把 session 同步给其他服务器,那么这样一来,服务器之间就一定会产生耦合,分布式也就没有意义了;
③ **共享session:**创建一个服务器来专门处理 session ,然后让其他服务器来调用它。但这么处理,如果这台服务器挂掉了,那不就完蛋,那还搞啥分布式啊,最后还是依赖一台服务器,所以也有缺陷。
④ 所以说,采用分布式部署的时候,不采用session,能在浏览器存储cookie就在浏览器存,如果实在重要的数据,可以存储在数据库中,数据库可以采用集群储存备份。、还可以将会话存储到Redis中。
生成验证码
Kaptcha
网址(开发手册,默认访问不了,需要用VPN):http://code.google.com/archive/p/kaptcha
- 导入jar包
<!--导入kaptcha包,为我,用于生成随机验证码-->