最近一个项目的服务器老是出现Session数据丢失问题，导致用户莫名其妙的退出，原因是太相信我们的运维人员所谓的负载均衡会话保持的概念。会话保持 的原理就是负载均衡通过Cookie来分发那个客户连接被路由到那台后端具体服务器，例如后端有两台服务器，负载均衡将会将所有的请求平均分配对应后端两 台服务器的cookie标识，后面的请求都会路由到具体的某台服务器上。但绝对不是万能的，我们就是因为太相信这个，才导致问题持续了很久没有发现具体的 原因。至于为什么不能保持会话，我到现在还没有想明白，也没有具体追问我们的运营人员。等有时间具体研究，这里只是提醒大家不要假设负载均衡会为你稳定地 保持会话，因为此类问题在用户量越大的时候越容易出现，出现的概率达到1%-2%，这对大规模的实时性项目是不能容忍的，例如在线集体考试。
那
么在上述问题的前提下，很多朋友首先想到的是Cluster，特别是搞JavaEE开发的人，但内存复制型的Cluster配置还是比较复杂的，效率不一
定能达到我们想象的效果，其Session的恢复机制还是牵涉到存储的问题。在PHP环境下大多数人直接默认采用PHP的文件Session存储策略，我
跟踪了一下PHP的Session创建机制，一下子让人毛色洞开，PHP在接收到一个用户请求时，首先从请求的Cookie里面拿Session
ID，只要拿到，不管三七二十一，就认定这个Session
ID了，即使当前没有发现具体的Session存在，它也会为你创建一个对应该Session
ID的会话。不像很多JavaEE应用服务器，只要没有Session，才不管你客户端传过来什么，它都独立会新建一个。PHP就Session处理这一
点，我们就可以做容错形式的集群了，最简单的方法就是让后端的多台服务器共享同一个Session存储区。就这么简单，简单的简直让人不可思议。
那很多人担心的是是否会发生Session存储文件读取锁定、等冲突呢？我的回答是，不会，如果会的话，单台机器也会。
文
件存储Session最大问题是每次一个请求发生，并且调用了session_start()，都会打开一次该文件，并且读取其中的内容到内存，当然向
Session写也是这样，所以很多对吞吐能力要求高的PHP配置中可能会采用Memcache等内存机制，但可以肯定地说，我们也可以像共享硬盘一样共
享Memcache，其核心的难点应该是如何让Memcache像一个共享存储一样。
一头雾水的问题终于解决了，我们解决这个问题最痛苦的是日志机制不完整，跨部门多，导致发现问题周折，但总算解决了，分享出来供大家参考，不要走我们的老路。