session原理

浏览器在第一次访问web服务器，服务器端会响应一个sessionId，并且把这个sessionId传输给浏览器，并以cookie保存sessionId到浏览器本地。

以后的访问会把这个cookie的sessionId以请求头的方式传给服务器，这样服务器就可以拿着这个sessionId进行查找，服务器中有没有此sessionId对应的用户，这样就能标识出哪个用户，如果有用户相关的业务，就是利用这个sessionId返回用户相关的业务。

本质就是浏览器客户端本地保存了sessionId，服务器端保存了sessionId和用户信息映射，这样就实现了web应用有状态化。

单体架构

在早期的单体架构中，也就是只有一台web服务器，虽然在web应用中也进行的分层设计，但其实本质是在代码逻辑级别，本身还是一个应用而已（或者说就是一个war/jar包）。

这个时期的session都是保存在本地的web服务器内存中，非常简单就能保持用户状态。

集群/分布式架构

随着业务的复杂度升高，和对应用性能、高可用的需求，系统演变成了集群和分布式架构。

集群架构可以看服务器A和服务器B，部署同一个应用A，就是为了提升性能和高可用目的；服务器C是部署了另一个应用B，代表系统不是单一业务，而是多个应用集合的，即分布式架构。

这个架构中，我们之前的session方案就会有问题，因为服务器端的session是存放在本地内存中的。请看下面的流程

1、用户A第一次访问系统，由负载均衡器映射到服务器A中
2、会在服务器A的本地内存中，存放着session
3、用户A第二次访问系统，又被随机分配到了服务器B中
4、但服务器B中是没有存放用户A的session的，所以此sessionId在服务器B中找不到对应的session，就会以为用户没有登录，就会引导用户去登录
5、这样就导致session不一致的问题。

session复制

session复制方案是一个服务器端的方案，对客户端是透明的，客户端不需要改变什么。看架构图

这个方案本质是利用了应用服务器自身的特性，如：tomcat。修改一下tomcat的配置文件，就是让应用服务器之间进行session复制，这样就可以达到每个服务器都有一样的session。

这个方案2-3个服务器还行，但服务器一旦多起来，就会有问题。
1、session之间的复制就会占用很大的网络带宽
2、session复制是有时间延迟的
3、服务器的内存是有限的，代表着session存放是有限的

session粘性

这个方案就利用负载均衡器的特性，把同一个浏览器的同一个用户都定向发送到同一个服务器上。看架构图

上图的核心思路，用户甲访问系统被负载均衡器一直分配到服务器A上，这样也就保证了用户一直在同一个服务器中进行查找session，保证了用户session一致性。

不过此方案也存在一些问题：

1、服务器的内存是有限的，代表着session存放是有限的
2、这个方案适用集群架构，但不适用分布式架构
3、一旦服务器拓展数量，session就会出现混乱

cookie方案

之前的方案都是在服务器端进行改造的，cookie方案是客户端的方案，就是把session信息保存到cookie中，即用户信息保存到cookie中，这样就不需要服务器保存session（用户信息）了。每次请求时，把此cookie传给服务器端，这样服务器端就知道是哪个用户了。

此方案比较实现比较简单，而且还不占用服务器端的内存资源。但是此方案的问题很大哦。

1、cookie在客户端是有限的，存储容量也是很小的
2、安全是很有问题的，因为保存在本地，很容易被人拿到

session外部存储

之前的服务器端改造的方案，**session都是存储到本地内存中的，导致一些问题。**此外部存储就是把思路进行改变，让session的存储与应用服务器隔离出来，看架构图

最后

面试题文档来啦，内容很多，485页！

由于笔记的内容太多，没办法全部展示出来，下面只截取部分内容展示。有想获取完整版笔记的朋友，点赞后点击这里免费领取哦

1111道Java工程师必问面试题

MyBatis 27题 + ZooKeeper 25题 + Dubbo 30题：

Elasticsearch 24 题 +Memcached + Redis 40题：

Spring 26 题+ 微服务 27题+ Linux 45题：

Java面试题合集：

pring 26 题+ 微服务 27题+ Linux 45题：**

[外链图片转存中…(img-0BPELV2P-1628221858671)]

Java面试题合集：