具体的问题
当一个带有会话表示的Http请求到Web服务器后，需求在请求中的处理过程中找到session数据。而问题就在于，session是保存在单机上的。 假设我们有应用A和应用B，现在一位用户第一次访问网站，session数据保存在应用A中。如果我们不做处理，怎么保障接下来的请求每次都请求到应用A呢? 如请求到了应用B中，就会发现没有这位用户的session数据，这绝对是不能容忍的。
常见解决方案
Session Sticky
保证同一个会话的请求都在同一个web服务器上处理，负载均衡器根据每次请求的会话表示进行转发。
1.png
问题：如果某一台服务器宕机或重启，那么这台服务器上的session数据就丢失了。如果session数据中还有登录状态信息，那么用户需要重新登录。负载均衡要处理具体的session到服务器的映射。
Session Replication
web服务器之间增加会话数据的同步，通过同步保证不同web服务器之间的Session数据是一致的。
2.png
好处：解决了Session Sticky对负载均衡的映射要求。
问题：同步Session数据造成了网络带宽的开销，增加每台机器的内存占用，不适合集群机器很多的场景。
Session数据集中存储
3.png
好处：解决了Session Replication方案中内存的问题，对于网络带宽也比它要好
问题：读写Session数据引入网络操作，存在延时和不稳定性，发生在内网的话影响不大；如果集中存储的Session机器或集群出问题则影响我们的应用
Cookie Based
把Session数据放在Cookie中，然后在Web服务器上从Cookie中生成对应的Session数据
4.png
好处：不会依赖外部的存储系统，不存在从外部系统读写Session数据的网络时延、不稳定问题。
问题：Cookie长度限制了Session数据长度；存在安全性问题；增加数据中心的整体外部带宽消耗；性能影响。
这4种方案都是可用的方案，不过这4种方案都各有优劣，需要根据具体的实际场景做出合适的选择
我们的方案
域名
统一级域名，*.aa.com，确保cookie数据从浏览器传递给集群服务器
会话
- 格式：键值对
Key：cookie值
Value：User对象序列化（包括用户信息、权限、店铺、企业信息等） - 全局会话
应用服务器远程访问，创建时设置过期时间t1（分钟），每次访问修改过期时间 - 本地会话
应用服务器本地访问，创建时设置过期时间t2，每次访问不修改这个过期时间，且t2<t1，尽量使t2隔一段时间就过期，过期后去访问远程缓存，重新修改时间t1.
运行原理
- 用户登录，保存会话数据至远程缓存服务器，并设置会话过期时间，当前系统时间+T1；
- 用户第一次访问应用服务器，应用服务器上无会话数据，须从远程缓存服务器获取会话数据，同时保持会话至本地，并设置本地会话过期时间，当前时间+T2，并重新设置远程缓存会话过期时间，当前系统时间+T1；
- 用户第二次访问应用服务器，应用服务器本地存在会话数据，直接从本地获取会话数据；
- 应用服务器上本地缓存的会话数据过期自动后失效
- 远程缓存服务上的会话数据过期后自动失效
会话更新
- 如果在应用服务A中进行会话(key=”xxx”)更新，如权限范围变大。
- 更新远程缓存中会话数据，服务器可以生成新的cookie值作为key。
- 从远程缓存获取此会话的原值，从值中获取保存过此会话缓存的其他应用服务器列表，服务器A以远程调用方式通知其他服务器删除本地会话(key=”xxx”)的缓存，以便下次从远程缓存重新加载一次最新会话数据。
问题
- 本地会话与远程会话可能不能完全同步，比如远程缓存故障丢失，本地还有此缓存数据。
- 用户在线列表，按用户查找会话困难，缓存服务器需要进行全遍历全部key.虽然有的缓存服务器如redis支持key的模糊查询，但是还是会影响性能急剧下降，CPU负载过高，官方不推荐使用。
- 如果要实现方便检索的会话，如按店铺、企业、用户、主机来检索会话，只得用关系数据库或NoSQL数据库来实现。
