分布式session一致性问题

传统的网站结构（并发量不大，没有session的不一致的问题。

传统的网站结构图：

   **结论：**从图中可以看出在传统的网站结构中，所有的客户端都连接一个服务器，每个客户端发送过来的请求都被该服务器处理，所以对于用户来说session是一致的不存在改变。我们都知道服务器是通过cookie中的JSESSIONID来判断该用户的身份，所以在该用户再发送其他请求是可以不需要验证的。但session也是有期限的，一但session过期用户就得重新登陆。现在有个问题要说的是如果用户在同个浏览器打开两个窗口session是否一致？其实服务器对用户的判断只是根据JSESSIONID ，它只认这id其他的看都不看一样，而我们又知道JSESSIONID又存在浏览器的cookie中，而同一浏览器打开两个窗口是共用一个cookie，因此session有可能会从。（不排除特殊情况）。

浏览器禁用cookie，我们怎么传SESSIONID呢？
答案：就是URL重写，注意在URL重写中的JSESSIONID的位置不是在？之后而是在？之前并且用；隔开。例如：http://127.0.0.1:8080/cookie/demo2.do;jsessionid=D2B0058380743E3731D50C49E6355144?age=12

分布式中session一致性问题

如图
 结论：从图中可以客户端发送一个请求，经过负载均衡后该请求会被分配到下列服务器中的任意一个，这时用户验证了，如果用户在发送一个请求，该请求被负载到了另一服务器上，此时检查cookie中的sessionid 发现该服务器没有，这是会出现用户的登陆。像这样每次请求每次验证肯定造成用户的体验极差，所以解决分布式session一致问题极其重要。下面我就讲讲分布式session中的问题吧。

什么是负载均衡和反向代理？

什么是负载均衡？：

负载均衡：将客户端的请求按照一定的规则分配到一群服务器中，并将处理结果返回个相应的客户端。

例如：上图client 发送请求A经过负载均衡（按照某一规则）分配到webserver1中，并且将请求的结果在返回客户端。如果并发量大的时，负载均衡就会很好的控制服务端处理的任务量，避免一个服务器处理量大，一个处于空闲。

负载均衡的实现

• 基于硬件方面。（但实际不怎么考虑，成本太大）

• 基于软件方面。（实际开发中应用最多）。

什么是反向代理：
要明白反向代理首先就得明白什么是正向代理什么是反向代理：所谓正向代理就是内网通过代理访问外网，这个代理就是正向代理，而反向代理其实与正向代理刚好相反，就是外网通过代理访问内网，这种代理模式就是反向代理。从中我们不难发现反向代理时外网访问内网时根本不知道那个服务器提供的服务，给人的感觉就是好像连接一个服务器。
反向代理与负载均衡一样，也是位于客户端与服务器之间，客户端向服务器发起的请求都是先经过反向代理，然后分发到服务器上，然后服务器将返回结果交给反向代理，反向代理再交割客户端。
二者的区别
最大的区别就是负载均衡只有在服务器大禹2台的时候才有意义，其主要侧重于将负载均衡到各个服务器上。

什么是会话保持，有什么作用

会话保持是指在负载均衡器上有一种机制，在作负载均衡的同时，还保持同一用户相关连的请求会被分配到同一台服务器上。

**会话保持的作用：**保证用户发送的请求在一定时间会被同一台服务器处理，而不是负载均衡到别的服务器。 所以会话保持有时间限制。如果只使用会话保持也不能解决session的问题，因此还的会话同步。

会话同步

网络集群时会同步的3中方法
在做了网络集群后，你肯定会首先考虑会话同步问题，因为通过负载均衡后，同一IP访问同一页面会被分配到不同的服务器上，如果会话不同步的话，一个登陆用户，一会是登陆状态，一会又不是登陆状态。

• 1 利用数据库同步会话（不常用）

在做多服务器会话同步时我没有用这种方法，如果非要用这种方法的话，我想过二种方法： a，用一个低端电脑建个数据库专门存放web服务器的会话，或者，把这个专门的数据库建在文件服务器上，用户访问web服务器时，会去这个专门的数据库检查一下会话的情况，以达到会同步的目的 .b，这种方法是把存放会话的表和其他数据库表放在一起，如果mysql也做了集群了话，每个MySQL的节点都要有这张表，并且这张会话表的数据表要实时同步。 说明：用数 库来同步会话，会加大数据库的负担，数据库本来就是容易产生瓶颈的地方，如果把会议还放到数据库里面，无疑是雪上加霜。上面的二种方法，第一点方法较好，把放会话的表独立开来，减轻了真正数据库的负担

• 2 利用cookie （cookie安全隐患）

同步会话是文件的形势存放在服务器端的，cookie是文件的形势存在客户端的，怎么实现同步呢？方法很简单，就是把用户访问页面产生的会话放到cookie里面，就是以cookie为中转站。你访问网络服务器A，产生了会话把它放到饼干里面了，你访问被分配到网页服务器B，这个时候，网络服务器乙先判断服务器有没有这个会话，如果没有，在去看看客户端的饼干里面有没有这个会议上，如果也没有，说明会议真的不存，如果饼干里面有，就把饼干里面的sessoin同步到网络服务器B，这样就可以实现会话的同步了。

说明：这种方法实现起来简单，方便，也不会加大数据库的负担，但是如果客户端把饼干禁掉了的话，那么会议就无从同步了，这样会给网站带来损失;饼干的安全性不高，虽然它已经加了密，但是还是可以伪造的。

• 3 利用memcache或者redis同步会话

memcache可以做分布式，如果没有这功能，他也不能用来做会话同步。他可以把web服务器中的内存组合起来，成为一个“内存池”，不管是哪个服务器产生的sessoin都可以放到这个“内存池”中，其他的都可以使用。

优点：以这种方式来同步会话，不会加大数据库的负担，并且安全性比用饼干大大的提高，把会议放到内存里面，比从文件中读取要快很多。 缺点：内存缓存把内存分成很多种规格的存储块，有块就有大小，这种方式也就决定了，内存缓存不能完全利用内存，会产生内存碎片，如果存储块不足，还会产生内存溢出。