在撩分布式session

一、背景

在搭建完集群环境后，不得不考虑的一个问题就是用户访问产生的session如何处理。如果不做任何处理的话，用户将出现频繁登录的现象，比如集群中存在A、B两台服务器，用户在第一次访问网站时，Nginx通过其负载均衡机制将用户请求转发到A服务器，这时A服务器就会给用户创建一个Session。当用户第二次发送请求时，Nginx将其负载均衡到B服务器，而这时候B服务器并不存在Session，所以就会将用户踢到登录页面。这将大大降低用户体验度，导致用户的流失，这种情况是项目绝不应该出现的。

二、session处理策略

2.1Session Sticky 方式管理

例如以下图所看到的：

server独立Session要求用户的每次请求都必须在同一台应用server上面操作，这就要求负载均衡server每次都能把用户的请求发送到同一个地址的server上面。

第一个用户第一次訪问的1号server。那个在用户的整个会话中都必须由负载均衡server导流到1号server上面。其它server不会保存1号用户的Session信息。

如今的负载均衡server一般都有这个功能（nginx）

可是假设出现以下的情况

这个时候1号server宕机的情况下，负载均衡server会把1号用户导流到2号或者3号server上面，可是用户在2和3号server上面没有安全的上下文环境。server会通知用户又一次登录。这样用户体验肯定会受到影响。并且非常可能用造成用户的数据丢失。

2.2Session Replication 方式管理 (即session复制)

每台server保留所实用户的Session这就关系到应用server之间的Session同步问题。实时性要求比較高。

这样的方式能够避免上面server独立Session所遇到的问题，例如以下图所看到的：

长处

这样的方式即使出现第一种情况那么2和3号server上面也保存的1号的Session信息，当出现故障负载均衡server把1号用户导流到2和3号server上面时。server也会发现有1号用户的安全上下文，能够继续訪问并且不须要又一次登录。

缺点

可是这样的方式也有缺点，那就是相应用server的Session同步实时性要求比較高，并且会带来额外的跨带开销。并且当Session之遥有变化时，就须要同步。假设Session里面的信息量比較大。那个会占用相当大的内存消耗。

2.3缓存集中式管理

server共享Session信息：

长处

每一个用户的Session信息都会被存储到应用之外的另外一台server（可能是数据库，也可能是KV存储服务），这样应用server就不用存储每一个用户的Session信息了，节约了非常大的内存开销。

当不同应用server须要用到Session信息的时候就去找共享Sessionserver来获取信息。

这样负载均衡server也就不用把用户固定的分配到一台server上面了，并且也不用server之间来复制Session信息，当Session信息发生改变时，应用server都去共享server改动信息就可以。

缺点

比較依赖于共享server，一旦共享server或者共享server集群出现故障。用户会收到非常大影响