Tomcat 5服务器为集群和SESSION复制提供了集成的支持。本系列的第一篇文章将为大家提供SESSION持久性以及TOMCAT集群中SESSION复制的内在工作机制一个概要认识。我将会讨论SESSION复制在TOMCAT5中是怎样进行的以及跨越多集群节点的SESSION持久性的复制机制。在第2部分，我会详细讨论一个带有SESSION复制功能的TOMCAT集群的安装例子，并且比较不同的复制情形。
集群
传统独立服务器（非集群的）不提供任何失效无缝转移以及负载平衡能力。当服务器失败的时候，就无法获取整个网站的内容，除非服务器被重新唤起。由于服务器失效，任何存储在服务器内存中的SESSION都会丢失，用户必须重新登陆并且输入所有由于服务器失效丢失的数据。
不同的是，作为集群一部分的服务器则提供了可测性以及失效无缝转移能力。一个集群就是一组同步运行并且协同工作，能提供高可靠性，高稳定性以及高可测性的多服务器例程。服务端集群对客户端表现出来似乎就是一个单独的服务器例程。从客户端的视角来看，集群的客户端和单独的服务器没多大不同，但是他们通过提供实效无缝转移和SESSION复制做到了不间断服务以及SESSION数据持久性。
集群中的服务器通讯
集群中的应用程序服务器通过诸如IP多点传送（IP multicast）和IP sockets这样的技术和其他服务器共享信息
●IP多点传送：主要用于1对多的服务器通讯，通过广播服务和 heartbeats消息的可用来显示服务器的有效
●IP sockets：主要用于在集群的服务器例程中进行P2P服务器通讯
使用ip多点传送进行一对多通讯
TOMCAT服务器使用IP多点传送在集群中的服务器例程间进行一对多的通讯，IP多点传送是一种能够让多服务器向指定IP地址和端口号进行订阅并且监听消息的广播技术（多点传送IP地址范围从224.0.0.0 到239.255.255.255）。在集群中的每个服务器都使用多点传送广播特定的 heartbeat消息，通过监视这些 heartbeat消息，在集群中的服务器例程判断什么时候服务器例程失效。在服务器通讯中使用IP多点传送的一个缺点是他不能保证这些消息被确实接收到了。例如，一个应用持续的本地多点传送缓存满了，就不能写入新的多点传送消息，等消息过了之后该应用程序就没有被通知到。
使用ip Sockets进行服务器通讯
IP sockets 同样也通过了一套在集群中的服务器间进行发送消息和数据的机制。服务器例程使用IP sockets 在集群节点间进行HTTP SESSION状态的复制。正确的SOKET配制对于集群的性能是至关重要的，基于SOCKET的通讯的效率取决于SOCKET的实现类别（例如：系统使用本地的或者纯JAVA SOCKET读取器实现），如果服务器使用纯JAVA SOCKET读取器则要看服务器例程是否注册使用了足够的SOCKET读取器线程。
如果想要有最佳的SOCKET性能，系统应该注册使用本地的SOCEKT而不是纯JAVA实现。这是因为相对于基于JAVA的SOCKET实现，本地SOCKET消耗更少的系统资源。虽然SOCKET读取器的JAVA实现是P2P通信中一种可靠而且可移动的方法，可是他不能为集群中的重型SOCKET使用提供最好的性能。当判断从SOCKET是否有数据读取的时候本地SOCKET读取器使用了更有效率的方法。使用本地SOCKET读取器实现，读取器线程不需要去统计静止的SOCKET：他们仅仅为活动的SOCKET服务，并且在一个给定的SOCKET开始活跃起来时他们可以立刻捕捉到。而使用纯JAVA SOCKET读取器，线程必须动态的统计所有打开的SOCKET，判断他们是否包含可读取的数据。换句话说，SOCKET读取器总是忙于统计SOCKET，即使这些SOCKET没有数据可读。这些本不应该的系统开销降低了性能。
TOMCAT 5中的集群
虽然在TOMCAT5的早些版本中也有集群的功能，但是在稍后的版本中（5.0.19或者更高），集群变的更加模块组件化。在 server.XML 中集群元素已经被重构，这样我们可以替换集群的不同部分而不会影响其他元素。例如，当前配置中把成员服务设置为多点传送发现。这里可以轻易地把成员服务修改替换为使用TCP或者 Unicast ，而不会改变集类逻辑的其他部分。
其他一些集群元素，例如SESSION管理器，复制发送端，复制接受端也可以被自定义的实现取代而不影响集群配置的其他部分。同样，在TOMCAT集群中的任何服务器组件可以使用集类API向集群中的所有成员发送消息。
SESSION复制
服务器集群通常操纵两种SESSION： sticky sessions和 replicated sessions .sticky sessions就是存在单机服务器中的接受网络请求的SESSION，其他集群成员对该服务器的SESSION状态完全不清楚，如果存有SESSION的服务器失败的话，用户必须再次登陆网站，重新输入所有存储在SESSION中的数据。
另一种SESSION类型是，在一台服务器中SESSION状态被复制到集群中的其他所有服务器上，无论何时，只要SESSION 被改变，SESSION数据都要重新被复制。这就是 replicated session . sticky 和 replicated sessions都有他们的优缺点， Sticky sessions简单而又容易操作，因为我们不必复制任何SESSION数据到其他服务器上。这样就会减少系统消耗，提高性能。但是如果服务器失败，所有存储在该服务器内存中的SESSION数据也同样会消失。如果SESSION数据没有被复制到其他服务器，这些SESSION就完全丢失了。当我们在进行一个查询事务当中的时候，丢失所有已经输入的数据，就会导致很多问题。
为了支持 jsp HTTP session 状态的自动失效无缝转移，TOMCAT服务器复制了在内存中的SESSION状态。这是通过复制存储在一台服务器上的SESSION数据到集群中其他成员上防止数据丢失以及允许失效无缝转移。
