当前位置: 首页 >> 工程机械

印刷厂控制应用程序故障切换的速度下

2021-08-18 来源:宜兴市机械信息网

印刷厂控制应用程序故障切换的速度(下)

使用可重新启动的事务

事务必须是可重新启动的,这样服务器出现故障且应用程序在另一系统上重新启动时,客户端才不必重新进入或回退事务。换句话说,如果事务过程中发生了故障,应该不需要从头再重新启动。这一能力使应用程序更为健壮,并且降低了用户觉察到故障切换的可能性。

一个常见的示例是打印作业。打印机应用程序通常对作业进行调度。打印作业完成后,调度程序转至下一项作业。但是,如果系统在打印较长作业(比如打印工资单需三小时)的过程中死机,那么系统恢复后会出现何种情况?作业是从头开始,重新打印所有的工资单,还是从上次中断处开始,调度程序是否会认为作业已经完成,而不再打印尚未打印的工资单?高可用性环境中的正确行为应是从上次中断处重新开始,确保每个人都得到一份工资单,并且只有一份。

另一个示例是在某个应用程序环境中,一个职员正在输入一个新员工的有关数据。假定该应用程序要求员工编号是唯一的,而在输入了新员工的姓名和编号后发生了故障。既然故障发生前已经输入了员工的编号,应用程序是否会拒绝重新输入员工的编号?它是否会要求首先删除已输入的部分信息?在高可用性环境中,应用程序较适当的行为应是允许此职员轻松地重新开始该项,或允许此职员继续输入下一个数据项。

使用检查点

将应用程序设计为可以用检查点记录复杂的事务。在用户看来非常简单的一项事务,实际上会分成多项数据库事务。尽管此问题关系到的是可重新启动的事务,但这里还是建议在客户端的本地记录进程,以便使被系统故障中断的事务能在故障切换后得以完成。

例如,假定使用的应用程序正在计算 PI。在原来的系统上,应用程序已经计算到了第 1,000

个小数,但应用程序尚未把任何数据写入磁盘。就在此刻,节点崩溃了。应用程序在另一个节点上重新启动,但要从头开始。应用程序必须重新计算那

1,000 个小数。但是,如果应用程序已定期将小数写入磁盘,则应用程序将会从中断处重新启动。

平衡检查点频率和性能

平衡检查点频率和性能很重要。在磁盘上使用检查点的代价是其对性能的影响。显然,如果过度频繁地使用检查点,应用程序就会变慢;如果使用检查点的频率不足,在发生故障切换后要花较长时间才能使应用程序恢复到当前状态。理想的情况是,最终用户应该能够决定使用检查点的频率。应用程序应提供可定制的参数,以便最终用户可以调节检查点的频率。

多服务器设计

如果使用多个处于活动状态的服务器,多个服务点就可以为客户端提供相对透明的服务。不过,这种功能要求客户端有一定的智能,以了解多服务器的相关信息,并且具有查询这些服务器地址的优先权。它还要求客户端能访问发生故障的服务器上的数据或复制的数据。

例如,不是让某个应用程序在出现故障时切换到另一个系统,而是要考虑使用两个系统来运行这个应用程序。在第一个系统出现故障后,第二个系统就接管第一个系统的工作。这就省去了应用程序启动的时间。设计这类体系结构有很多方法,这类设计也涉及到很多问题。不过,除给出一些示例外,本文将不讨论有关细节。

最简单的方法是让两个应用程序以主/从关系运行,其中从应用程序只是主应用程序的热备用程序。当主应用程序出现故障时,第二个系统上的从应用程序仍需要判断数据处于什么状态(也就是说,还会发生数据恢复)。但是,这样可以省去派生应用程序以及进行初始启动的时间。

另一种可能是拥有两个处于活动状态的应用程序。比如有两个应用程序服务器都在伺服一个数据库。客户端的一半连接到第一个应用程序服务器上,另一半连接到第二个应用程序服务器上。如果一个服务器出现故障,那么所有的客户端都连到剩下的那个应用程序服务器上。

复制数据站点的设计

复制数据站点对快速地实现故障切换和灾难恢复都有帮助。有了复制的数据,数据磁盘就不在系统间共享,也就不需要进行数据恢复。这样就加快了恢复的速度。不过,复制数据可能会影响性能。复制数据有很多方法,应用程序设计人员应对此进行全面的研究。

很多标准数据库产品都向客户端应用程序提供透明的数据复制功能。将应用程序设计为使用标准数据库后,最终用户就可以决定是否需要进行数据复制了。

来源:广州印刷网

声明:

本文来源于网络版权归原作者所有,仅供大家共同分享学习,如作者认为涉及侵权,请与我们联系,我们核实后立即删除。

友情链接