应用服务器的高可用架构设计主要基于服务无状态这一特性，但是事实上，业务总是有状态的。
在交易类的电子商务网站，需要有购物车记录用户的购买信息，用户每次购买请求都是向购物车中增加商品；
在社交类的网站中，需要记录用户的当前登录状态。
Web应用中将这些多次请求修改使用的上下文对象称作会话（Session），单机情况下，Session 可由部署在服务器上的Web容器管理。在集群环境下，由于负载均衡服务器可能会将请求分发到集群中任何一台应用服务器上，所以保证每次请求依然能够获得正确的Session 比单机时要复杂的多。
集群环境下，Session 管理的主要手段有以下几种：
Session 复制
Session 绑定（会话粘滞）
cookie记录Session
Session 服务器
接下来，我们逐一进行介绍。
一、Session 复制
在服务器之间进行 Session 同步操作，每个服务器都有所有用户的 Session 信息，因此用户可以向任何一个服务器进行请求。
缺点：
占用过多内存
同步过程占用网络带宽以及服务器处理器时间
二、Session 绑定
Session 绑定（Sticky Session），又叫会话粘滞。需要配置负载均衡器，使得一个用户的所有请求都路由到同一个服务器，这样就可以把用户的 Session 存放在该服务器中。（这时负载均衡服务器必须工作在HTTP协议层上，比如反向代理负载均衡）
缺点：
当服务器宕机时，将丢失该服务器上的所有 Session。
三、Cookie记录Session
浏览器Cookie记录Session。
优点：简单易用，支持应用服务器线性伸缩
缺点：受Cookie大小限制，能记录的信息有限；每次请求响应都要传输Cookie，影响性能；用户关闭Cookie，访问不正常
四、Session 服务器
可用性搞、伸缩性好、性能不错，对信息大小又没有限制的服务器集群Session管理方案——Session服务器。利用独立部署的Session服务器（集群）统一管理Session，应用服务器每次读写Session时，都访问Session服务器。
这种解决方案事实上是将应用服务器的状态分离，分为无状态的应用服务器和有状态的Session 服务器，然后针对这两种服务器的不同特性分别设计其架构。
优点： 为了使得大型网站具有伸缩性，集群中的应用服务器通常需要保持无状态，那么应用服务器不能存储用户的会话信息。Session Server 将用户的会话信息单独进行存储，从而保证了应用服务器的无状态。
缺点： 需要去实现存取 Session 的代码。
这里重点要了解第四种——Session服务器，对于有状态的Session服务器，一种比较简单的方法是利用分布式缓存、数据库等、在这些工具的基础上开发组件，使其符合Session的存储和访问要求。如果业务场景对Session管理有比较高的要求，比如利用Session服务集成单点登录（SSO）、用户服务等功能，则需要开发专门的Session服务管理平台。
在后面的文章中我会重点讲解单点登录（SSO），我之所以专门来讲解Session管理，就是为了后续更好的讲解单点登录。
原文：https://www.cnblogs.com/littlewhiterabbit/p/13218944.html