session跨域共享问题解决方案

在讨论session跨域共享问题之前，我们首先要了解session做了什么，没做到什么

1. HTTP是无状态的，也就是说服务器不知道谁访问过他，但是有时候，又需要我们去保留这个状态比如说用户的登录信息，如果每次访问都要登陆，这个用户体验实在是太糟糕了，session就解决了这个问题，他把用户登陆信息维护在服务端，会生成一个JSessionID给客户端，客户端下次访问的时候就带着这个JSessionID，服务端根据这个ID去查找用户信息。
2. 当然，session的缺点也很明显，session是存在服务器的内存中的，如果session过多会影响服务器的性能。因为session只在一台服务器里，当有多台服务器的时候，访问别的服务器肯定会失败。

明确了session所做的事以及它的缺陷之后，解决session存在的问题就容易多了，下面我简要说一下5种解决方案

• Session Sticky
• Session复制
• Session集中存储
• Cookie
• Token

Session Sticky :是指让同一客户端的请求，落在同一台服务器上，因为不会落在别的服务器上，所以自然就不会出现跨域问题。但是这个方案的缺点非常的明显，就是不管比采用什么算法，用户的请求落在哪一台服务器上都是由用户来决定的，可能会造成单点压力，并且如果一台服务器出问题，可能会造成一片区域的人无法访问

Session复制 ：是指服务器之间互相同步session信息，也就是说每台服务器上都保存着所有的session信息。这样做的缺点也是非常明显的。上文提到过，session是存在内存中的，会严重影响服务器性能，当然，你也可以把他存在数据库中，但是这会大大影响响应速度。还有一个缺点就是，当访问量过大时，由于互相同步的问题，会造成大量的网络开销

Session集中存储：是指把Session集中存储在一个第三方的服务器中，可以是Redis,可以是数据库或是其它什么东西。当需要访问的时候，都去这个服务器去查。这样做也有不小的缺点，首先是单点问题，如果这个服务器宕机，那么所有的服务都是不可用的，所以这里必须做集群，会浪费服务器资源。还有一点是，每次验证都需要来这个服务器来查，会凭白增加一次网络开销，降低访问速度

Cookie ：状态信息不再保存在服务端，而是保存在客户端，客户端每次访问服务器的时候，把这个信息带给服务器。但是Cookie也有不少问题，最被人关注的就是安全问题，因为信息是保存在客户端的，就比较容易被人盗取、篡改，当然这些安全问题都是有解决方案的，这不是限制Cookie的主要原因，真正限制Cookie的原因是很多设备**不支持**Cookie

Token :和Cookie类似，Token也是由客户端来维持状态的，信息存储在客户端内，具有平台无关性。Token实质上是服务端给客户端的一个字符串，上面包含着一些验证信息，相当于一个身份令牌，你拿着这个令牌就能得到他的服务。相比较于Cookie，Token更加的灵活，可以在任何地方生成，基于Token的权限系统是非常容易实现的

当然，解决方案并不只上面5种，我只是列举了几个有代表性的。

方案是用来解决问题的，上面的这些方案没有好不好的说法，只有合不合适的说法，合适的才是最好的。