Session共享方案答题.docx

Session共享方案 cookies存储，避免使用session cookies长度有限制，不要超过4K sid 通过cookies保存 application集群 tomcat的session复制 tomcat集群中的session管理，主要有两种方式： 1).粘性session 表示从同一窗口发来的请求都将有集群中的同一个tomcat进行处理。配置方式是在上面perties文件中 Xml代码?? worker.lbcontroller.sticky_session=True??? 粘性session的好处在不会在不同的tomcat上来回跳动处理请求，但是坏处是如果处理该session的tomcat崩溃，那么之后的请求将由其他tomcat处理，原有session失效而重新新建一个新的session，这样如果继续从session取值，会抛出nullpointer的访问异常。 2).session复制 session复制是指tomcat彼此之间通过组播方式将session发到各个tomcat实例上，如果其中一个访问出错，则另外tomcat仍然具有有效的session内容，从而能正常接管其session。坏处是当tomcat实例很多，或者用户在session中有大量操作时，组播发送的信息量十分惊人。session复制配置则是在发布的web应用程序中的web.xml中添加 集中存储 持久化、内存 工作原理： 数据库存储 使用redis来存储 ? ?此体系结构中,?redis master出现故障时,?通过haproxy设置redis slave为临时master, redis master重新恢复后, 再切换回去. 此方案中, redis-master 与redis-slave 是双向同步的, 解决目前redis单点问题. 这样保证了session信息在redis中的高可用。 使用memcached来保存session msm支持 stickty（沾粘会话）和non-sticky（非沾粘会话）两种集群方式。 sticky就是前端的loadbalance能保证每个用户的请求都路由到了同一个tom HYPERLINK /command/cat.html \t _blank cat上。 负载均衡很重要，绑定还是到tomcat集群好。 不要使用sticky方式。 non-sticky则每一次请求都可能路由到了不同的tomcat中。 MSM(memcached-session-manager)?支持tomcat6?和tomcat7?，利用?Value（Tomcat?阀）对Request进行跟踪。Request请求到来时，从memcached加载session，Request请求结束时，将tomcat session更新至memcached，以达到session共享之目的，?支持?sticky ?和?non-sticky?模式。 ? ???????Sticky?模式：tomcat session?为?主session，?memcached?为备?session。Request请求到来时，?从memcached加载备?session到?tomcat (仅当tomcat jvmroute发生变化时，否则直接取tomcat session)；Request请求结束时，将tomcat session更新至memcached，以达到主备同步之目的。 ?安装在Tomcat上的MSM使用本机内存保存session，和StandardManager一样。另外，当一个请求结束时，session会被送回Memcached进行备份。当下一次请求开始时，本地Session可用，直接服务，请求结束后，session又被送回Memcached备份。 当集群中的一个Tomcat挂掉，下一次请求会被路由到其他Tomcat上。负责处理此此请求的Tomcat并不清楚Session的信息。此时它会从Memcached查找该Session，更新该Session并将其保存在本机内容。此次请求结束，session被修改，送回Memcached备份。 ? . What else？ 上边介绍的是处理Tomcat故障转移，MSM又是如何处理Memcached故障转移呢？ 如果一个Memcached故障，当前Memcached中的Session会转移到其他Memcached节点，同时，JSESSIONID被修改并送回浏览器。 如果使用黏性Session，应确保loadbalancer中配置生成的JSESSIONID无任何后缀。 SESSIONID的格式 MSM知道Memcached节点列表，这些节点标识会存储在SESSIONID中，SESSIONID值类似：602F7397FBE