Tomcat群集系列第4部分：使用备份管理器进行会话复制

嗨，这是我的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 使用备份管理器进行会话复制 。

翻译自: https://www.javacodegeeks.com/2012/12/tomcat-clustering-series-part-4-session-replication-using-backup-manager.html