问题
为了满足足够大的应用，满足更多的客户，于是我们架设了N台Web服务器（N>=2），在多台Web服务器的情况下，我们会涉及到一个问题：用户登陆一台服务器以后，如果在跨越到另一台服务器的时候能够继续使用客户的Session？
1、写客户端Cookie的方式
把原来存储在服务器磁盘上的session数据存储到客户端的cookie中去。(一般是把session数据按照自己定义的加密规则（如：采用DES、RSA等进行明文加解密；再由MD5、SHA-1等算法进行防伪认证），加密后后存在cookie中。)
优势
服务器的压力减小了，因为session数据不存在服务器磁盘上，无需额外的服务器资源。根本就不会出现session读取不到的问题。
劣势
- 网络请求占用很多。每次请求时，客户端都要通过cookie发送session数据给服务器。要占用很多带宽了，成本增高(服务器购买带宽是一个很大费用)。
- 浏览器对cookie的大小个数都存在限制。每个浏览器限制是不同的（大概4kb左右）。
- 安全问题，虽然通过了加密，等你不能保证不会被人解密
总结：
这方案不适合高访问量的情况下，因为高访问量的情况下，每次请求浏览器都要发送session数据给服务器。一般一个cookie大小2k的样子。
2、sticky模式(粘性会话模式)
用一种算法(简单理解为规则)，什么机制下session是保存在哪台服务器下，那么读取的时候就按照这种规则去读取，就能定位到原来的服务器。叫做分发请求，分发到特定的服务器上去，其原理是存session和读session数据保证都在一台服务器操作，就不会需要涉及到共享，具体实现方式是通过约定一种分发机制来实现(如Nginx下的ip_hash、Apache下的stickysession等)。
也叫做sticky模式(粘性会话模式)，同一个用户的访问请求都被派送到同一个服务器上。
优势
本地维护Session，不需要做session数据共享了。
劣势
一台服务器宕机后，当前Session断掉。
总结：
本来负载均衡有一个目的就是：当其中一台机子不可用的时候，会自动分发到可用的机子上去(自动判断现在要请求的机子是否可用),但此方法一台服务器出现问题,该服务器下的用户都不能用了
3、利用数据库共享Session数据
首选当然是大名鼎鼎的Mysql数据库，并且建议使用内存表Heap，提高session操作的读写效率。
优势
保存在数据库中，这种方式的扩展性很强，可以随意增加WEB而不受影响。放在数据库里面安全方面好。
劣势
- session的并发读写能力取决于Mysql数据库的性能
- 当访问量大时，每个用户都要频繁的访问session，造成mysql服务器压力过大
- 由于http是短连接，每次过程是：建立连接(握手)->数据通信->通信结束后结束连接。如果频繁的这样子连接后再断开(每次都会去数据库查询session)，性能会非常差。
4、利用NFS共享Session数据
NFS是Net FileSystem的简称，最早由Sun公司为解决Unix网络主机间的目录共享而研发。
通过nfs的方式，各个服务器操作session数据的时候，是读取本地磁盘目录，但实际上是一个共享网络文件。各个服务器实际上操作的都是同一个目录的文件。
优势
这个方案实现最为简单，无需做过多的二次开发，仅需将共享目录服务器mount到各频道服务器的本地session目录即可。
劣势
缺点是NFS依托于复杂的安全机制和文件系统，因此并发效率不高，尤其对于session这类高并发读写的小文件，会由于共享目录服务器的io-wait过高，最终拖累前端WEB应用程序的执行效率。
5、基于内存（Redis、Memcache）的Session共享
相比较与其他方式，该方式是目前最好的session共享方案
可以将session数据保存在memcached，redis之类内存数据库中，memcached是基于内存存储数据的，性能很高，用户并发量很大的时候尤其合适。
建议使用redis，支持的数据格式比较多、能够查看在线用户、数据不容易丢失，支持持久化等
优势
- 主要是利用内存的数据读取速度是很快的，与磁盘读取的速度不是一个数量级的。
- 使用内存存储：方便统计在线人数，内存的速度比磁盘访问快、内存数据库系统能够控制内存中的过期数据自动失效(刚好符合session过期需要)。