当网站业务规模和访问量的逐步增大，原本由单台服务器、单个域名组成的迷你网站架构可能已经无法满足发展的需要。此时我们可能会购买更多的服务器，并且已频道化的方式启用多个二级子域名，然后根绝业务功能将网站非别部署在独立的服务器上，或者通过负载均衡技术让多个频道共享一组服务器。
如果我们把网站程序分别部署到多台服务器上，而且独立为几个二级域名，由于Session存在实现原理上的局限性（PHP中Session默认已文件的形式保存在本地服务器的硬盘上），这使得网站用户不得不经常在几个频道间来回输入用户名和密码登陆，导致用户体验大打折扣。另外，原本程序可以直接从用户Session中读取的资料（如昵称、积分、登陆时间等），因为无法跨服务器同步Session变量，迫使开发人员必须实时写数据库，从而增加了数据库的负担。于是，解决网站跨服务器的Session共享问题的需求就变得迫切起来，最终催生了多种解决方案。
1、基于Cookie的Session共享
这种方案我们可能比较陌生，但它在大型网站中是被普遍使用了的。其原理是将全站用户Session信息加密、序列化后以Cookie的方式同一植在根域名下。当浏览器访问该根域名下的所有二级域名站点（包括www）时，将与域名相对应的所有Cookie内容特性传递给它，从而实现用户的Cookie化Session在多服务间的共享访问。
这个房展的优点是无需额外的服务器资源；缺点是由于受HTTP协议头信息长度的限制，仅能够存储小部分的用户信息，同时Cookie话的Session内容需要进行安全加密（如：采用DES、RSA等进行明文加解密，再由MD5、SHA-1等算法进行防伪认证），另外它也会占用一定的带宽资源，因为浏览器会在请求当前域名下的任何资源时将本地Cookie附加在http头中传递到服务器上。
2、基于数据库的Session共享
首选当然是大名鼎鼎的MySQL数据库，并且建议使用内存表Heap。以提高Session操作的读写效率。这个方案的实用性比较强，相信大家普遍在使用。它的缺点在于Session的并发读写能力取决于MySQL数据库的性能，同时需要我们自己来实现Session淘汰逻辑，以便定时从数据表中更新、删除Session记录，当并发过高时容易出现锁表，虽然我们可以选择行级别锁的表引擎，但不得不否认使用数据库存储Session还是有杀鸡用牛刀之嫌。
3、基于Memcache的Session共享
Memcache是一款基于Libevent的多路异步I/O技术的内存共享系统，简单的Key+Value数据存储模式使其代码逻辑小巧高效，因此在并发处理能力上占据了绝对优势。
另外，值得一提的是，Memcache的内存Hash表所特有的Expires数据过期淘汰机制，正好和Session的过期机制不谋而合，这就降低了删除过期Session数据代码复杂度。但对于“基于数据库的存储方案”，仅逻辑这块就给数据表带来了巨大的查询压力。
事实上，我们在工作中也发现，以上方案除了Cookie以外，其他两种方法均会给数据库带来巨大的查询压力。而我们的MySQL本身压力就非常大，这无疑是雪上加霜。其实我们应该在规则网站架构时就应该设计好，将程序集中防止在单台WEB服务器上，并且用二级域名来保存海量的图片文件等，这样就可以通过F5/LVS的简单会话保持功能，以及Nginx的IP_HASH、HAproxy的balance source机制来让用户始终与后端的一台WEB服务器保持通信，这样Session共享的问题就轻松解决了。
转载请注明：LINUX服务器运维架构技术分享 » 实现Session共享的几种方法