服务集群session问题

1. http协议本身无状态，可通过Session与Cookie记录前端与后端服务器的交互状态；

2. 但是每次客户端回传必须在头信息中带有cookie, 如果session过多，会增加数据传输量；

3. 改进：每次回传一个session id，标记每个客户的唯一性；如果cookie被禁用，将这个session id 放在url中；

4. 集群session共享问题：

        a). session sticky机制：让负载均衡根据session id来转发请求，

             problem1：如果服务宕机了，需要重新登录另一台；

             problem2:  对负载均衡也会带来其它问题（有待补充）；

        b). session replication机制：节点之间做session同步，这样不必负载均衡对同一用户的每次会话请求必须转发到同一个节点上；   

              problem1：session 复制，会造成网络宽带开销（节点越多，开销越大）；

              problem2：如果用户很多，每个节点保存session的开销也会增大；

              部署方式：以tomcat为例，每个节点的server.xml配置中增加cluster配置（receiver和address因每个节点不同，其它均相同）；web.xml增加<distributable />；在服务器上开启Membership和Receiver使用的端口；注意：保存到session中的对象需要实现Serializable接口，否则会复制失败；

         c). session集中存储：可以是数据库存储，可以是分布式存储；但如果存储session的节点不在一个内网，会存在请求延迟和不稳定，如果存储session的节点有问题，会对应用造成影响；但相对于Session Replication，当节点器数量比较大、Session数比较多的时，集中存储方案比较合适。

         d). cookie based机制：将session信息写入每个请求用户的浏览器里；

              problem 1：但cookie有长度限制，如果session太多，不适用；         

              problem 2：而且有网络安全问题（虽可加密，但最好不要屋里接触）；

              problem 3:  响应数据太多，影响响应效率；

总结：对应大型web应用，节点较多，session sticky和session集中存储比较实用；如果只有两三个节点，session replication比较实用；