用户Session 会话机制

博由

    本文针对：用户Session在不同的系统场景如何解决？进行分析和记录。

Session策略

1个站点

在展开话题之前，先看看一个普通的分布式站点是咋样的？



Cookie 保存会话

[1] 发生位置：用户侧（例如：浏览器）
[2] 实现方式：将用户信息（会话信息）保存在cookie中，在每次请求时，将这些信息传送到server进行解析；一般来说，cookie存储的会话内容都会进行加密（例如：md5/sha等）；这种方式主要依赖于cookie的存在，cookie本身是存储在用户侧，因此安全性不能得到保证，容易被串改和劫持；还有一个点就是cookie存储的内容是有限的，只能存在小数据；

交互流程:

总结：
1、cookie 本身问题（存储有限、安全性不高）；
2、实现简单；
如果出现cookie禁用情况，可以通过明文URL传递参数可以解决，但是同样是安全性问题；

Session Sticky（粘性会话）

[1] 发生位置：负载均衡（LVS）部分；
[2] 实现方式：负责均衡来记录用户方式服务器的关系，例如：用户1 访问了 服务器1，那么每次确保用户1路由到服务器1，这样就能确保和单机Session的情况一样，但是缺点就是：
1、LVS存储了用户侧和服务器的关系，变成了有状态；
2、如果服务器1挂了，那么用户1要么无法访问，要么就需要进行重新登陆；

交互方式：

总结：通过中间负载设备，每次用户访问时，会存储用户与服务器之间的关系，确保每次该用户都路由到同一个服务器，从而和单机情况基本一致，就不会出现重复登陆情况，那么这种情况会导致两个不好的点：
1、负载设备：从无状态变成有状态，并且存储了用户和服务器关系信息，存储容量也需要进行考虑；
2、单机场景：这种方式其实就是避免的分布式集群情况的Session不一致问题，但是却同样引来了单点服务器的问题，如果服务器挂了：
a、负载均衡不做处理：那么用户是无法继续访问站点；
b、路由到其他可用服务器，那么需要用户重新登陆；

Session Replication（Session复制）

[1] 发生位置：服务端集群侧；
[2] 实现方式：后台服务器之间进行Session数据复制，这种方式仅仅适用于服务器数量少的情况，如果多的话，服务器之间的数据复制，会越来越到，这只是一种实现方式，正常情况不会这么做的。

交互方式：

总结：
如果要在服务器这一层来解决Session问题，那么只要确保服务器之间Session数据是一致的就可以，换句话说，1-n号机存储的Session保持一致，那么无论那一台服务器挂了，都不需要重新登陆，这是实现的原理。那么就需要提供一个保证服务器Session一致的工具；如果说集群数量比较大，那么复制的动作非常之大，假设1号机Session变化（删除、更新、增加）都需要同步到2-n号机，负担是非常之大的；一般只适用于小集群数量和用户量少的情况，不是很推荐使用；

集中存储

[1] 发生位置：存储侧（例如：DB）
[2] 实现方式：将会话数据存储在诸如：数据库、redis等存储设备中；实现原理很简单，就是集中Session存储，不会存在某个服务器挂了，需要用户重新登陆的情况，如果访问量比较大的话，数据库的压力会比较大，这个可以通过做Session cache来提高效率（一般采用redis、memcache等）；

交互方式：

总结：Session复制是依据Session数据一致的问题来解决的，那么还有一个思路就是：将Session数据共享处理，集中化存储。因此我们需要选择一个集中存储Session的存储媒介（一般是数据库，例如：mysql），这样的化会建立三层关系：
第一层：服务器Session缓存；
第二层：缓存中间件（redis）；
第三层：存储媒介（MySQL）；
如果用户进行访问时，会先看访问的服务器Session严重是否ok，如果不ok，那么查询redis，最后再查询mysql，最终mysql不存在才需要用户重新登陆。这里需要注意的是：缓存一致性的问题，本文不针对展开。
这种方式使用比较常见。

总结

解决分布式Session问题，我们针对比较常见的分布式站点的结构布局，在不同层通过不同的方法来解决session问题。可以分为：
1、用户侧：例如：浏览器，可以通过Cookie存储用户密文验证信息，优点就是处理很简单，缺点就是安全性问题；
2、负载侧：单机环境下是不存在Session问题，那么我们可以通过负载路由策略来保证用户的访问到固定的机器上，这样就构造了一个单机环境，那么单点环境存在的问题，在这里依旧存在，例如：服务器挂了，用户访问不了；虽然可以通过路由策略转到其他可用服务器，但是还是需要用户重新登陆；
3、服务侧：分布式环境下由于用户流量导入到不同的机器上，会导致每台机器存储的Session不尽相同，那么用户一会访问服务器，一会访问服务器2，就会导致用户重新登陆，因此我们可以通过考虑服务器间的Session数据是一致的，这样就需要一个工具来保证Session在变化时服务器之间的Session数据同步，这种方式很少使用，因为当用户数据（Session）多时，服务器多时，会导致Session的同步很多很频繁，效率不好。但是也不失为一种解决方式；
4、存储侧：思路就是Session数据共享，那么就需要存储Session数据的媒介，一般会是数据库；这样就不会出现服务器之间的Session复制，同时也可以集中管理和维护Session信息，但是问题也有，就是当访问量大的时候，数据库可能成为瓶颈，这个可以通过加入cache层来解决问题，这种方式，比较常用；