什么是session：
服务器为每个用户创建一个会话，存储用户的相关信息，以便多次请求能够定位到同一个上下文。
当用户请求来自应用程序的 Web 页时，如果该用户还没有会话，则 Web 服务器将自动创建一个 Session 对象。当会话过期或被放弃后，服务器将终止该会话并销毁。
分布式session：
以往单服务器的项目，我们不需要考虑session共享问题，因为session也在该服务器中。
现在随着互联网的发展，用户数量激增，单服务器已经无法满足；集群方式部署服务器已经在很多公司运行起来，当高并发量的请求到达服务端的时候通过负载均衡的方式分发到集群中的某个服务器，这样就有可能导致同一个用户的多次请求被分发到集群的不同服务器上，就会出现取不到session数据的情况，于是session的共享就成了一个问题。
第一种方案：
部署专门管理session的服务器来管理session；当其他服务器读取session的时候都需要去访问session服务器。
这种解决方案事实上是应用服务器的状态分离，分为无状态的应用服务器和有状态的session服务器，然后针对这两种服务器的不同特性分别设计架构。
有状态的session服务器，一种比较简单的方法是利用分布式缓存（redis、memcached), 或者存储在数据库(如MySQL)等。在这些产品的基础上进行包装，使其符合session的存储和访问要求。
如果业务场景对session管理有比较高的要求，比如利用session服务基层单点登录（sso),用户服务器等功能，需要开发专门的session服务管理平台。
优点：可靠性比较好
缺点：实现比较复杂、稳定性依赖于缓存的稳定性、Session信息放入缓存时要有合理的策略写入。
session服务器使用场景：集群中机器数多、网络环境复杂。
第二种方案：
cookie管理session；
session记录在客户端，每次请求服务器的时候，将session放在请求中发送给服务器，服务器处理完请求后再将修改后的session响应给客户端，这里的客户端就是cookie。
缺点：受cookie大小的限制，能记录的信息有限；
每次请求响应都需要传递cookie，影响性能；
如果用户关闭cookie，访问就不正常。
优点：cookie的简单易用，可用性高，支持应用服务器的线性伸缩。
第三种方案：
ession绑定；
利用hash算法，比如nginx的ip_hash,使得同一个Ip的请求分发到同一台服务器上。
session绑定使用场景：机器数适中、对稳定性要求不是非常苛刻
优点：实现简单、配置方便、没有额外网络开销
缺点：网络中有机器Down掉时、用户Session会丢失、容易造成单点故障。
第四种方案：
使用token代替session，现在很多企业都使用这种方式解决分布式session共享问题。
