分布式系统中Session共享的常用方案

分布式Session一致性？

说白了就是服务器集群Session共享的问题

Session的作用？

Session 是客户端与服务器通讯会话跟踪技术，服务器与客户端保持整个通讯的会话基本信息。

客户端在第一次访问服务端的时候，服务端会响应一个sessionId并且将它存入到本地cookie中，在之后的访问会将cookie中的sessionId放入到请求头中去访问服务器，如果通过这个sessionid没有找到对应的数据那么服务器会创建一个新的sessionid并且响应给客户端。

分布式Session存在的问题？

假设第一次访问服务A生成一个sessionid并且存入cookie中，第二次却访问服务B客户端会在cookie中读取sessionid加入到请求头中，如果在服务B通过sessionid没有找到对应的数据那么它创建一个新的并且将sessionid返回给客户端,这样并不能共享我们的Session无法达到我们想要的目的。

解决方案：

• 使用cookie来完成（很明显这种不安全的操作并不可靠）
• 使用Nginx中的ip绑定策略，同一个ip只能在指定的同一个机器访问（不支持负载均衡）
• 利用数据库同步session（效率不高）
• 使用tomcat内置的session同步（同步可能会产生延迟）
• 使用token代替session
• 使用spring-session或者集成好的解决方案，session存放在redis中

0x01：基于数据库的Session共享

首选当然是大名鼎鼎的Mysql数据库，并且建议使用内存表Heap，提高session操作的读写效率。这个方案的实用性比较强，经常被使用，它的缺点在于session的并发读写能力取决于Mysql数据库的性能，同时需要自己实现session淘汰逻辑，以便定时从数据表中更新、删除 session记录，当并发过高时容易出现表锁，虽然可以选择行级锁的表引擎，但不得不否认使用数据库存储Session还是有些杀鸡用牛刀的架势。

0x02：基于Cookie的Session共享

这个方案可能比较陌生，但它在大型网站中还是比较普遍被使用。原理是将全站用户的Session信息加密、序列化后以Cookie的方式， 统一 种植在根域名下（如：.host.com），利用浏览器访问该根域名下的所有二级域名站点时，会传递与之域名对应的所有Cookie内容的特性，从而实现户的Cookie化Session 在多服务间的共享访问。

这个方案的优点无需额外的服务器资源；缺点是由于受http协议头信心长度的限制，仅能够存储小部分的用户信息，同时Cookie化的 Session内容需要进行安全加解密（如：采用DES、RSA等进行明文加解密；再由MD5、SHA-1等算法进行防伪认证），另外它也会占用一定的带宽资源，因为浏览器会在请求当前域名下任何资源时将本地Cookie附加在http头中传递到服务器

0x03：基于Memcache的Session共享

Memcache由于是一款基于Libevent多路异步I/O技术的内存共享系统，简单的 Key + Value 数据存储模式使得代码逻辑小巧高效，因此在并发处理能力上占据了绝对优势。另外值得一提的是Memcache的内存hash表所特有的Expires数据过期淘汰机制，正好和Session的过期机制不谋而合，降低了过期Session数据删除的代码复杂度，对比基于数据库的存储方案，仅这块逻辑就给数据表产生巨大的查询压力。

0x05：基于Redis的Session共享

该方案使用Redis来存储用户的登录状态，Redis服务器也存在多做存储数据的淘汰策略，与Session的过期机制非常类型。目前该方案是互联网公司最广泛使用的方案，没有之一。Spring还专门开发了一个分布式Session的组件。