Tomcat 服务器为集群和SESSION复制提供了集成的支持本系列的第一篇文章将为大家提供SESSION持久性以及TOMCAT集群中SESSION复制的内在工作机制一个概要认识我将会讨论SESSION复制在TOMCAT中是怎样进行的以及跨越多集群节点的SESSION持久性的复制机制在第部分我会详细讨论一个带有SESSION复制功能的TOMCAT集群的安装例子并且比较不同的复制情形
集群
传统独立服务器（非集群的）不提供任何失效无缝转移以及负载平衡能力当服务器失败的时候就无法获取整个网站的内容除非服务器被重新唤起由于服务器失效任何存储在服务器内存中的SESSION都会丢失用户必须重新登陆并且输入所有由于服务器失效丢失的数据
不同的是作为集群一部分的服务器则提供了可测性以及失效无缝转移能力一个集群就是一组同步运行并且协同工作能提供高可靠性高稳定性以及高可测性的多服务器例程服务端集群对客户端表现出来似乎就是一个单独的服务器例程从客户端的视角来看集群的客户端和单独的服务器没多大不同但是他们通过提供实效无缝转移和SESSION复制做到了不间断服务以及SESSION数据持久性
集群中的服务器通讯
集群中的应用程序服务器通过诸如IP多点传送（IP multicast）和IP sockets这样的技术和其他服务器共享信息
●IP多点传送主要用于对多的服务器通讯通过广播服务和 heartbeats消息的可用来显示服务器的有效
●IP sockets主要用于在集群的服务器例程中进行PP服务器通讯
使用IP多点传送进行一对多通讯
TOMCAT服务器使用IP多点传送在集群中的服务器例程间进行一对多的通讯IP多点传送是一种能够让多服务器向指定IP地址和端口号进行订阅并且监听消息的广播技术（多点传送IP地址范围从 到）在集群中的每个服务器都使用多点传送广播特定的 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实现是PP通信中一种可靠而且可移动的方法可是他不能为集群中的重型SOCKET使用提供最好的性能当判断从SOCKET是否有数据读取的时候本地SOCKET读取器使用了更有效率的方法使用本地SOCKET读取器实现读取器线程不需要去统计静止的SOCKET他们仅仅为活动的SOCKET服务并且在一个给定的SOCKET开始活跃起来时他们可以立刻捕捉到而使用纯JAVA SOCKET读取器线程必须动态的统计所有打开的SOCKET判断他们是否包含可读取的数据换句话说SOCKET读取器总是忙于统计SOCKET即使这些SOCKET没有数据可读这些本不应该的系统开销降低了性能
TOMCAT 中的集群
虽然在TOMCAT的早些版本中也有集群的功能但是在稍后的版本中（或者更高）集群变的更加模块组件化在 serverxml 中集群元素已经被重构这样我们可以替换集群的不同部分而不会影响其他元素例如当前配置中把成员服务设置为多点传送发现这里可以轻易地把成员服务修改替换为使用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数据到集群中其他成员上防止数据丢失以及允许失效无缝转移
对象的状态管理
通过在服务器上的保存状态可以区分出种对象
●无状态一个无状态对象在调用的时候不会在内存中保存任何状态因为客户端和服务器端没必要保存任何有关对方的信息在这种情况下客户端会在每次请求服务器时都会发送数据给服务器SESSION状态被在客户端和服务器端来回发送这种方法不总是可行和理想的特别是当传输的数据比较大或者一些安全信息我们不想保存在客户端的时候
●会话一个会话对象在一个SESSION中只被用于特定的某个客户端在SESSION中他可以为所有来自该客户端的请求服务并且仅仅是这个客户端的请求贯穿一个SESSION两个请求间的状态信息必须保存会话服务通常在内存中保存短暂的状态当在服务器失败的时候可能会丢失SESSION状态通常被保存在请求间的服务器的内存中为了清空内存SESSION状态也可以被从内存中释放（就像在一个对象CACHE）在该对象中性能和可量测性都有待提高因为更新并不是被单独的写到磁盘上并且服务器失败的时候数据也没办法抢救
●缓存缓存对象在内存中保存状态并且使用这个去处理从多客户端来的请求缓存服务的实现可以扩展到他们把缓存的是数据备份保存在后端存储器中（通常是一个关系数据库）
●独立的一个独立的对象在一个时间内只活跃在集群中的一台服务器上处理来自多客户端的请求他通常由那些私有的持久的在内存中缓寸的数据支持他同样也在内存中保持短暂状态在服务器失败的时候要重建或者丢失当失败的时候独立对象必须在同一个服务器上重起或者移植到另一台服务器上
(来源: Using WebLogic Server Clusters)
SESSION复制的设计考虑事项
网络考虑事项
把集群的多点传送地址和其他应用程序隔离是至关重要的我们不希望集群配置或者网络布局干扰到多点传送服务器通信和其他应用程序共享集群多点传送地址将迫使集群的服务器例程处理不应该的消息消耗系统内存共享多点传送地址可能也会使IP多点传送缓沖过载延迟服务器 heartbeat 消息传输这样的延迟可能导致一个服务器例程被标识为死亡仅仅因为他的 heartbeat 消息没有被及时接收
编程考虑事项
除了上面提到的网络相关因素还有些和我们写 JEE 网络应用程序有关的设计考虑也会影响SESSION复制以下列出了一些编程方面的考虑
●SESSION数据必须被序列化为了支持HTTP session 状态的内存内复制所有的 servlet 和 JSP session 数据必须被序列化对象中的每个域都必须被序列化这样对象被可靠的序列化
●把应用程序设计为幂等的幂等的的意思就是一个操做不会修改状态信息并且每次操作的时候都返回同样的结果（换句话说就是做多次和做一次的效果是一样的）通常WEB请求特别是 HTML forms 都被发送多次（当用户点击发送按纽两次重载页面多次）导致多次HTTP请求设计SERVLET和其他WEB对象为 幂等的可以容忍多次请求详细可以去参考设计模式Synchronized Token 和Idempotent Receiver 关于怎样设计幂等的的应用程序
●在BUSINESS层存储状态会话状态应该使用有状态的SESSION BEANS存储在EJB层而不是存储在WEB层的HttpSession因为企业应用程序要支持各种类型客户端（WEB客户端JAVA应用程序其他EJB）存储数据在WEB层会导致在客户端的双数据存储因此有状态的SESSION BEAN在这些情况下就被用于存储SESSION状态无状态的SESSION BEAN要为每次的调用重构造会话状态这些状态可能必须从数据库中恢复的数据中重编译这些缺点失去了使用无状态SESSION BEAN去提高性能和可测量性的目的严重的减低了性能
●序列化系统消耗序列化SESSION数据在复制SESSION状态的时候回会些系统消耗随着序列化对象大小的增长消耗也越多最好是保持SE
