交互流程图
集群环境下的 session 共享问题如果网站请求流量较大，那么单台 tomcat 设备是无法承接这些流量的，这个时候就需要开始对服务器做集群。
采用了多台机器做集群以后，就势必要通过一种机制来实现请求的路由。因为对于用户来说，我访问的是一个域名，至于后端应该请求到哪一台，用户并不需要关心。所以这里会使用负载均衡设备；
负载均衡负载均衡的主要目的是：把用户的请求分发到多台后端的设备上，用以均衡服务器的负载。我们可以把负载均衡器划分为两大类：硬件负载均衡器和软件负载均衡器。
硬件负载最常用的硬件负载设备有 F5 和 netscaler、Redware，F5是基于 4 层负载，netscaler 是 7 层负载。所谓的四到七层负载均衡，就是在对后台的服务器进行负载均衡时，依据四层的信息或七层的信息来决定怎么样转发流量四层的负载均衡，就是通过发布三层的 IP 地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡，转发至后台服务器，并记录下这个 TCP 或者 UDP 的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。七层的负载均衡，就是在四层的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比如同一个 Web 服务器的负载均衡，除了根据 VIP(virtual ip)加 80 端口辨别是否需要处理的流量，还可根据七层的 URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，如果你的 Web 服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。硬件负载均衡设备的有点是稳定性高、同时有专门的技术服务团队支撑。但是价格比较贵，一般的都要几十万起。所以那种大的企业，没有专业的运维团队。直接花钱买解决方案。软件负载比较主流的开源软件负载技术有: lvs、HAProxy、Nginx 等，对于小公司来说或者大型的互联网企业，基本都采用软件负载均衡技术来实现流量均衡。不同的负载均衡技术有不同的特点，比如 LVS 是基于 4 层的负载负载技术，抗负载能力比较强HAProxy 和 Nginx 是基于 7 层的负载均衡技术，需要根据请求的 url 进行分流
负载均衡算法引入负载均衡器以后，就势必需要一个负载均衡算法对请求进行转发，那么，常见的负载均衡算法有以下几种轮询算法及加权轮询算轮询法是指负载均衡服务器将客户端请求按顺序轮流分配到后端服务器上，以达到负载均衡的目的。假设现在有 6 个客户端请求，2 台后端服务器。当第一个请求到达负载均衡服务器时，负载均衡服务器会将这个请求分派到后端服务器 1；当第二个请求到害时，负载均衡服务器会将这个请求分派到后端服务器 2。然后第三个请求到达，由于只有两台后端服务器，故请求 3 会被分派到后端服务器 1对于后端服务器的性能差异，可以对处理能力较好的服务器增加权重，这样，性能好的服务器能处理更多的任务，性能较差的服务器处理较少的任务。假设有 6 个客户端请求，2 台后端服务器。后端服务器 1 被赋予权值 5，后端服务器 2 被赋予赋予权值 1。这样一来，客户端请求 1，2，3，4，5 都被分派到服务器 1 处理；客户端请求 6 被分派到服务器 2 处理。接下来，请求 7，8，9，10，11 被分派到服务器 1，请求 12 被分派到服务器 2
随机算法随机法也很简单，就是随机选择一台后端服务器进行请求的处理。由于每次服务器被挑中的概率都一样，客户端的请求可以被均匀地分派到所有的后端服务器上。
哈希算法根据获取客户端的 IP 地址，通过哈希函数计算得到的一个数值，用该数值对服务器列表的大小进行取模运算，得到的结果便是客服端要访问服务器的序号。采用源地址哈希法进行负载均衡，同一 IP 地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问。
Session 共享问题的解决方法Session 共享问题，其实已经有非常多的解决方案，那么接下来我们一一分析session stickysession sticky(粘性) , 保证同一个会话的请求都在同一个web 服务器上处理，这样的话，就完全不需要考虑到会话的问题了。比如前面说的负载均衡算法中，哈希算法就是一个典型的实现手段。这种实现方式会有些问题：
-
如果一台 web 服务器宕机或者重启，那么这台机器上保存的会话数据都会丢失，会造成用户暂时无法访问的问题，或者用户之前的授权操作需要再执行一次
-
通过这种方式实现的 session 保持，没有办法进行 4 层网络转发，只能在 7 层网络上进行解析并转发session replicationsession 复制通过相关技术实现 session 复制，使得集群中的各个服务器相互保存各自节点存储的 session 数据。tomcat 本身就可以实现 session 复制的功能，基于 IP 组播放方式。大家课后可以去了解下如何配置这种实现方式的问题：1 同步session数据会造成网络开销，随着集群规模越大，同步 session 带来的带宽影响也越大2 每个节点需要保存集群中所有节点的 session 数据，就需要比较大的内存来存储。
session 统一存储集群中的各个节点的 session 数据，统一存储到一个存储设备中。那么每个节点去拿 session 的时候，就不是从自己的内存中去获得，而是从相应的第三方存储中去拿。对于这个方案来说，无论是哪个节点新增或者修改了 session 数据，最终都会发生在这个集中存储的地方。这个存储设备可以是 redis、也可以是 mysql。
这种实现方式的问题：1 读写 session 数据需要进行网络操作，存在不稳定性和延迟性2 如果存储 session 的服务器出现故障，将大规模的影响到应用示例参见 redis保存session信息 https://blog.csdn.net/zhangxm_qz/article/details/88047583
Cookie Based （cookie 的基础）
Cookie Based 方法，简单来说，就是不依赖容器本身的Session 机制。而是服务端基于一定的算法，生成一个 token 给到客户端，客户端每次请求，都会携带这个 token。当服务端收到 token 以后，先验证 token 是否有效，再解密这个 token 获取关键数据进行处理
1.背景介绍什么是Cookie
Cookie 是在HTTP协议下，服务器或脚本可以维护客户工作站上信息的一种方式。Cookie 是由 Web
服务器保存在用户浏览器（客户端）上的小文本文件(内容通常经过加密)，它可以包含有关用户的信息。无论何时用户链接到服务器，Web站点都可以访问
Cookie 信息,可以看作是浏览器缓存.
什么是Session
Session的定义很抽象,在不同的场合中session一词的含义也很不相同.它可以代表服务器与浏览器的一次会话过程,指从一个浏览器窗口打开到关闭的这个期间.也可以用于指一类用来在客户端与服务器之间保持状态的解决方案.
2.知识剖析Cookie机制
Cookie需要解决三个问题：分发、内容和使用。
cookie的分发是通过扩展HTTP协议来实现的，服务器端通过在HTTP的响应由中加上一行特殊的指示以提示浏览器按照指示生成相应的cookie。
cookie的内容主要包括name(名字)、value(值)、maxAge(失效时间)、path(路径),domain(域)和secure
name：cookie的名字，一旦创建，名称不可更改。
value：cookie的值，如果值为Unicode字符，需要为字符编码。如果为二进制数据，则需要使用BASE64编码.
maxAge：cookie失效时间，单位秒。如果为正数，则该cookie在maxAge后失效。如果为负数，该cookie为临时cookie，关闭浏览器即失效，浏览器也不会以任何形式保存该cookie。如果为0，表示删除该cookie。默认为-1
path：该cookie的使用路径。如果设置为"/sessionWeb/"，则只有ContextPath为“/sessionWeb/”的程序可以访问该cookie。如果设置为“/”，则本域名下ContextPath都可以访问该cookie。
domain:域.可以访问该Cookie的域名。第一个字符必须为".",如果设置为".google.com",则所有以"google.com结尾的域名都可以访问该cookie",如果不设置,则为所有域名
secure：该cookie是否仅被使用安全协议传输。
cookie的使用是由浏览器按照一定的原则在后台自动发送给服务器。浏览器检查所有存储的cookie，如果某个cookie所声明的作用范围大于等于将要请求的资源所在的位置，则把该cookie附在请求资源的HTTP请求头上发送给服务器.
Session机制
Session机制是一种服务端的机制，服务器使用一种类似散列表的结构来保存信息。当程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端里的请求里是否已包含了一个session标识--sessionID，如果已经包含一个sessionID，则说明以前已经为此客户端创建过session，服务器就按照sessionID把这个session检索出来使用（检索不到，可能会新建一个），如果客户端请求不包含sessionID，则为此客户端创建一个session并且声称一个与此session相关联的sessionID，sessionID的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串(服务器会自动创建),这个sessionID将被在本次响应中返回给客户端保存。
保存sessionID的方式
1，使用Cookie.此时Cookie不再用作认证,只是作为载体,存储sessionID
2，URL重写：因为cookie可以被人为禁止，所以为了保证sessionID能够被传递给服务器，使用URL重写也是一种解决方法。如,
href="<%=response.encodeURL("index.jsp") %>"
写好后URL是这样的
href="index.jsp;jsessionid=0CCD096E7F8D97B0BE608AFDC3E1931E"
3, 隐藏表单提交.将sessionId放在隐藏表单中
实际上这几种方式最方便的还是cookie,其他两种方式都各有弊端,URL重写的弊端是要对所有的URL都重写,非常繁琐.表单隐藏字段的弊端是只能局限于表单提交,如果是单纯的文本链接则不能提供会话跟踪
Cookie和Session之间的区别
1.Cookie数据存放在客户的浏览器(本地),session数据放在服务器上
2.Cookie不如session安全，别人可以分析存放在本地的Cookie并进行Cookie欺骗,所以出于安全性的考虑应当使用Session
3.Session会在一定时间内保存在服务器上。当访问增多,会占用较多的服务器资源,所以出于性能考虑则应当使用cookie
单个cookie保存的数据不能超过4k,很多浏览器都限制一个站点最多保存20个cookie.实际上为了性能考虑,不论是cookie还是session,其中的信息都应当短小精悍
session因为是保存在服务器上,所以不支持跨域的访问
3.扩展思考使用cookie和session的具体场景
一般来说,登陆验证信息,客户的私人信息,如姓名,电话等,应该放在Session中.Cookie则用于用户登陆网站时的自动登陆以及类似"购物车"的处理.使用Cookie保存信息时最好通过加密形式来保存数据,同时是否保存登陆信息,需要由用户自行选择