这是最简单的实现方式，数据库还能在整个系统都当掉时依旧保存好session数据，可靠性高，几乎所有J2EE实现都提供了这种方式，当然，你的session数据必须是可序列化的。但是，这种方式一般推荐不要在session中存放过大过多的数据，因为数据库的事务过程相当费资源，但这样也大大限制了它的使用范围，毕竟我们有时必须要在session中存放一些大对象
内存拷贝方式
虽然实现起来容易，但这种方法的弊端也显而易见，当节点增加时，拷贝量就要成倍增长，性能有时还不如不集群
Weblogic, Jboss 和 WebSphere的实现：双服务器拷贝
虽然这种方法的性能和扩展性都很好，但也有不少弊端
l负载均衡器的复杂度加大，因为要记住每个服务器的备份者是谁
l除了处理请求外，每个服务器还得自己维护备份开销
l平时大量的内存都被用于备份数据，会增加jvm的垃圾收集频率，间接影响性能
l一旦某个服务器长时间挂掉，那么另一台服务器的负荷就会翻倍，可能也被一起拖垮
为了克服以上缺点，各个厂商都有自己的不同解决方案
IBM的方案：中央服务器
很像是之前的数据库方式吧，只是把数据库换成了一台专门备份的服务器，综合了数据库和内存方式的优点。
l将备份和请求处理分开，增强了系统的鲁棒性
l所有的备份数据都在专门的服务器上，节省了其他服务器的内存
l所有服务器都能存取备份机器上的数据，任何服务器宕机了，负载都能平滑的分配到剩余所有服务器上，而不至于加重某台机器的负担
l比起数据库连接，备份服务器使用的socket连接更加轻量级
比起直接的双服务器互拷内存，这种方式效率还是比较低的，因为还要有个恢复的过程，而且在管理上也增加了系统的复杂度。此外，备份服务器本身也很有可能成为瓶颈。
Sun的实现：专用数据库
表面上就是数据库的方式，但实际上，Sun JES应用服务器使用的称为“HADB”的数据库是专门为session的备份做了优化的，其大部分数据都是直接存放在内存中
Session备份的性能考虑
集群中每台服务器都有多个web应用，每个应用又同时有数以千记的用户session，这些session的备份和恢复都会耗费大量资源。更恐怖的是，session一直在变，比如失效了，比如增加或修改某个属性了，等等。所以如何备份session是考验系统架构水平的
何时备份？
不管是用数据库还是内存方式，下面两点都是比较常见的考虑
l按web 请求，即每次请求都进行备份更新，这样可以保证备份的数据是最新的
l固定时间备份，虽然不能保证备份的session是最新的，但却可以提高性能
备份粒度
l全部备份，最保险也是最慢的方法
l备份修改过的session。通常的做法是检测”HTTPSession.setAttribute()” 或“HTTPSession.removeAttribute()” 的调用，当然你要保证session的状态只能由这两个方法更改，尽管这不是J2EE规范的要求。
l备份修改过的session的属性，最节省性能的做法。但是有一点很重要：防止交叉引用。如下图，session中包含school对象，指向一个student对象。当school对象某个属性改变后，被备份到AS2中，它此时引用的是旧的student对象。接着student对象被单独改变了，也进行了备份，但是school中仍然引用旧的student。因此这种方法对web容器的设计要求很高，尽管它的性能是最好的。
图十三：session复制中的交叉引用
其他失效备援的实现
以上不论是数据库还是内存复制，归根结底都要使用Java的序列化机制，这给web容器的性能造成了不小的影响，因此有些应用服务器使用别的方式进行session备份
JRun with Jini
JRun 4使用jini实现集群，jini的详细介绍请参考 http://java.sun.com/products/jini/2_0index.html
Tangosol with Distributed Cache
Tangosol Coherence™提供了一个分布式数据管理平台，可以嵌入到大部分J2EE系统中，此外还提供一个分布式缓存系统，能够在多台jvm上有效的共享缓存，详情请参考 http://www.tangosol.com/