集群环境下的Session处理

在单台服务器情况下session处理比较简单，一旦到了集群环境中，我们就必须考虑用户和会话的问题，如果不加处理的话，一旦后端IP轮询切换，会话cookies找不到session，会话就中断了。在此情景下，通常有以下5种解决方案。

1. 依然使用集群，但集群的轮询策略改成hash ip

将每一个用户和后端服务器绑定，这样用户的会话就会一直落在同一台服务器上，这是成本最小的解决方案，只需要修改Nginx服务器的配置即可。如果是在比较老的架构上，推荐这种改造方案。

upstream backend {
        ip_hash;
        server bk1.abc.com;
        server bk2.abc.com;
        server bk3.abc.com;
}

这种解决解决方案也存在局限性，比如某台服务器挂了切换到另一台服务器，对应的会话也就丢了。还有另外一个问题，如果前端用了CDN的话，客户端IP变化的频率可能是很高的，有可能一个小时或更短时间内就变一次，这在校园网的网络环境下很容易产生这种情况。

2. 使用Session复制方案

顾名思义，Session复制就是让集群里的每台服务器都存储整个集群所有服务器上的全部session。这样一旦某台服务器挂了，用户切换到其他服务器上也能访问到一样的session数据。这种解决方案不好的地方在于进行session复制需要额外的网络开销和系统资源，当服务器较多或session中存储的数据量大的时候，这个问题尤为明显。

Session复制本身的操作是比较复杂，但是对于服务器来说，配置比较简单，但性能是个很大的问题。当集群中服务器数量大于两台时就比较吃力了，总之这是一种比较早期时候的解决方案。

3. Nginx的sticky方案

sticky方案和方案1类似，但是sticky能把会话死死地粘滞在其中一台服务器上，算是对方案1的补充，可以避免在CDN网络波动下的IP冲突造成的会话丢失。但是依然无法解决服务器挂掉导致会话丢失的问题。

4. NoSQL的几种存储方案

基于Redis等NoSQL的session集中存储方案，是目前最流行的解决方案，早期用MySQL来存储。引入Redis的方案除了会增加系统复杂度外，依然还有以下几个问题：

• 1. Redis有单点，要解决单点问题就得使用redis的集群方案，比如Codies
• 2. 用户量大的情况下，用来连接redis的类库可能存在瓶颈，比如性能不稳定、高并发容易挂的问题等等。

5. 放弃Session使用Cookie

使用纯cookie，不使用session，天然分布式。存在问题：

• 1. Cookies需要加解密，性能消耗需要考虑。而且储存空间有限，如果存放了复杂的数据，序列化本身也是一个消耗。
• 2. 对于浏览器而言，每次请求都会带上Cookies，包括js/css等静态资源，浪费带宽，可以考虑为静态资源单独部署一个子域名。

需要注意的是，如果应用需要做“禁止同时登录”的需求时，用Cookie的话解决起来会麻烦很多。

另外可以把cookie换成token等方式验证用户，每次请求带上token作为会话凭据。