什么是session
用户A通过输入username/pwd登陆微博网站，但是他不想这几天每次访问网站都输入user/pwd这太麻烦了。他需要网站记录他的登陆状态（最近两天登陆过），直到登陆状态过期后才需要重新输入user/pwd来登陆。
session就是为了解决该问题而来，通过保存用户登录状态给用户提供好的用户体验且同时保障用户的信息安全。
session 的实现机制也是随着系统演进逐步演进的。我们web服务经历过单机、分布式的过程，随着web架构的发展session的实现方式也会变化。下面重点描述session的实现机制如何随着 web架构的的演进而演进。
单机时代
单机时代session存放在servlet服务器中。通过浏览器传过来的sessionId来标识session，sessionId传送方式可以是cookie也可以是urlRewrite（cookie禁用时使用该方式）。
其具体如何交互请看下面的图：
分布式下session实现机制
沿着单机的思路，我们看如下session交互图：
在上图中，如果browseA经过负载均衡把请求转到了服务器B中的话，那么就会提示browserA 没有找到会话需要重新登录（事实上browseA 已经登录会话存放在服务器A中）。
怎么解决分布式下session一致的问题呢？
很容易想到，对于browserA发送的请求经过负载均衡器（在负载均衡器中做了手脚）时固定发送到服务器A上，这就是 session Sticky的方式。
我们分析session sticky 方式的优缺点：
1.在session sticky方式中sessin 只保留在一台机器上，比如sessionA保存在服务器A上这会有单点的问题。
2.我们需要维持会话<-->服务器映射，比如（sessinA<-->服务器A，sessionB<-->服务器B），此时需要应用层解析会有一定的开销，且负载均衡服务器成为了一个有状态的节点相对难以维护。-
第2种方式，我们把session复制到对应的机器。
image.png这种方式会有如下缺点：
1.多了一份存储消耗，会带来很多的带宽消耗，所以不适合多机房的场景。
2.需要一个定时任务来不停的同步这就会有一点的延迟。
-第3种方式，我们可以想到把session单独存放起来比如放在第三方缓存里，这就是session集中存储的方式。
在本人做过的项目中，需要考虑到session的安全性。比如useId存放在cookie中，userInfo存放在memcache中。此时为了防止userId被篡改需要在服务器端做一层校验。怎么做校验呢？通过同时传送和比较md5（userId）和userId明文来实现。具体流程请看下图：
- 第四中方式，由于session本身是由用户产生合并何不就存放在用户端（浏览器里），每次请求把session通过cookie的方式带到服务器，这样服务器就可以使用了，这就是cookie base的方式。
其具体使用方式见下图：
从图中可以看到每次把session带来带去其效果相当于一直存放在服务端。当服务端拿到cookie后解析放到threadLocal缓存中就可以供本次请求后续使用了。image.png
当然这种方式也有缺点：
1. session全部存放在cookie中会受到cookie长度的限制。
2.完全暴露在cookie中会有安全性问题，我们可以通过第3种方式中描述的对其md5实现。
3.会带来一定的网络带宽。
