嗨,这是我的Tomcat Clustering Series的第四部分。 在本文中,我们将讨论如何在tomcat群集环境中使用Backup Manager设置会话复制。 会话复制使群集环境具有高可用性和完整的故障转移功能。
[查看下面的视频以获得更好的理解]
这篇文章是我上一篇文章(使用Delta Manager进行会话复制)的延续。 在增量管理器中,每个tomcat实例都需要将会话信息复制到所有其他tomcat实例。 如果增加群集大小,则需要花费更多时间并进行复制,因此,这里有一个备用管理器,即备份管理器。
备份管理器将会话数据的副本完全复制到群集中的另一个tomcat实例。 这是增量管理器和备份管理器之间的主要区别。 这里,一个tomcat实例维护会话的主要副本 ,而另一个tomcat实例则保留复制的会话数据作为备份 。 如果任何一个tomcat实例失败,则另一个实例服务于该会话。 这样就可以实现故障转移功能。
备份管理器的设置过程与增量管理器相同。 除了需要在<Cluster>元素内将Manager称为BacupManager( org.apache.catalina.ha.session.DeltaManager
)。
假设我们有3个tomcat实例, 如上一篇文章 ,我已配置到备份管理器中。
现在,用户尝试访问该页面。 用户请求到达负载均衡器,负载均衡器将请求重定向到tomcat1。 现在tomcat一个创建了会话,现在tomcat1负责将一个副本正好复制到任何一个tomcat。 因此,tomcat1会选择属于群集(多播)的任何tomcat。 在这里tomcat1选择tomcat3作为备份。 因此,tomcat3保留了会话的备份副本。
我们正在粘性会话模式下运行负载平衡器,因此来自该特定用户的所有其他请求都将仅重定向到tomcat1。 tomcat1中的所有修改都复制到tomcat3中。
现在tomcat1由于某种原因而崩溃/关闭
现在,同一用户尝试访问该页面。 这次负载均衡器尝试重定向到tomcat1,但是tomcat1处于关闭状态,因此负载均衡器从其余的tomcat中选择了一个tomcat。 有趣的是,这里有2个案例。
情况1:假设负载均衡器选择了tomcat3,然后tomcat3接收到请求,并且tomcat3本身保留了会话的备份副本。 因此,tomcat3使该会话成为主副本,而tomcat3选择任何一个tomcat作为备份副本。 因此,这里仅剩下一个tomcat。 因此,tomcat3将会话复制到tomcat2。 现在,tomcat3保存了主副本,tomcat2保存了备份副本。 现在,tomcat3将响应发送给用户。 所有进一步的请求都由tomcat3(粘性会话)处理。
情况2:假设负载均衡器选择了tomcat2,然后tomcat2收到了请求,而tomcat2没有会话。 因此tomcat2会话管理器(备份管理器)询问所有其他tomcat管理器:“嗨,有人为这个用户举行了会话(基于会话ID [cookie])”。 实际上,tomcat3具有备份会话。 因此,tomcat3通知tomcat2并将会话复制到tomcat2。 现在,tomcat2使该会话成为主副本,而tomcat3使其已经具有会话副本作为该会话的备份副本,因此现在tomcat2保留主副本,tomcat3保留备份副本。 现在,tomcat2将响应发送给用户。 所有进一步的请求都由tomcat2(粘性会话)处理。
因此,无论哪种情况,我们的会话都是由备份管理器复制和维护的。 这对于大型集群很有用。
查看下面的视频
在我的github仓库中检查我的配置或获取ZIP文件
屏幕投射:
参考: Tomcat集群系列第4部分: Ramki Java Blog博客上的JCG合作伙伴 Rama Krishnan 使用备份管理器进行会话复制 。