tomcat集群的failover机制

---

集群要提供高可用性就必须要有某种机制去保证，常用的机制为failover（故障转移），简单说就是通过一定的heartbeat检测是否有故障，一旦故障发生备份节点则接管故障节点的工作。

tomcat使用BackupManager模式管理会话必须由负载均衡器提供会话黏贴（Session Stick）机制配合，所谓会话黏贴其实是一种会话定位技术，即在tomcat节点上生成一种包含位置信息的会话id，一般是附带了tomcat实例名，当客户端再次请求时负载均衡器会解析会话id中的位置信息并转发到响应节点上，例如对客户端的请求解析出tomcat1则把请求转到tomcat1，解析出tomcat3则转到tomcat3。假如使用apache作为load-balancer则可以使用Mod_JK实现会话黏贴。

如下图，看看在不同的故障情况下BackupManager会话管理器是如何处理让故障不影响整体的可用性的。一个请求会话包含了tomcat1信息，通过apache负载均衡器后定位到集群的tomcat1节点，此客户端对应的会话标识为id1，会话备份件存放在tomcat2节点上，假如tomcat1一直运行得很好，那么客户端每次的请求都将到此节点处理，此节点包含了用户的会话对象，所以涉及到会话的逻辑运算都没问题。但假设集群中有节点发送故障宕机了，这时的failover机制应该如何考虑？

（一）tomcat3或tomcat4宕了，请求依然转发到tomcat1，无需做任何额外处理。

（二）tomcat2宕了，请求依然转发到tomcat1，涉及到会话相关处理的逻辑仍然正常，但tomcat1需要做一些额外工作，包含新备份节点选取、把会话备份到新节点上等等。

（三）tomcat1宕了，请求可能转发到其它任一节点，分两种情况：

①　转发到备份节点tomcat2上，能找到对应的会话备份件，涉及到会话相关的运算逻辑正常，但它需要做一些额外工作，包含将自己升为源节点、从tomcat3或tomcat4中选一个备份节点，将会话备份到选出的节点。

②　转发到代理节点tomcat3或tomcat4上，由于不能在本地找到对应的会话对象，它要根据会话的位置信息向tomcat2获取会话对象，此外再将自己升为源节点。

BackupManager会话管理器的整个failover机制比较清晰明了，可能有一点会产生疑惑，某个节点宕掉后由它生成的会话经过apache会分发到哪些节点？会不会随机分发？例如当tomcat1宕了，sessionid.tomcat1会话第一次请求转发到tomcat3，第二次请求会转发到哪？实际情况是他会一直转发到tomcat3，因为tomcat整个处理过程存在一个JvmRouteBinderValve阀门，它的作用是提供检测会话路由功能，当它检测到会话的会话ID包含的路由信息非本地JVM时，它将会对其进行更改，例如sessionid.tomcat1转发到tomcat3时会被改为sessionid.tomcat3，也正是有此保证才得以实现BackupManager的failover机制。